The 100 examples in ScaleGrowth’s WebMCP Engineering Field Guide are useful as a catalogue of candidate tasks. Their value comes from choosing an example whose inputs, data access and effects match an actual business task. A product lookup and an order lookup may both leave records unchanged, but the order lookup can disclose private information. That difference can exclude an example before any registration code is written.
WebMCP lets a web application expose JavaScript tools that agents can invoke through descriptions and structured inputs. The draft Community Group Report dated 16 October 2026 is not a W3C Standard or on the Standards Track. The catalogue should be read against that changing technical context, rather than treated as a current implementation contract.
What the catalogue actually contains
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, co-authored WebMCP Made Simple Complete Edition. AEO means answer engine optimization; GEO means generative engine optimization. The book’s title page describes a combined plain-language guide and engineering field guide, and identifies the code as illustrative. The engineering overview directs readers to adapt the registrations and verify the current API before production use.
Appendix B, “The 100 Tools, by Industry”, contains ten numbered examples in each of ten industries. The completed decision index accompanying this article retains all 100 entries with their industry, example number, required inputs and source code. It assigns one primary functional category to each entry, while recording access and state-change questions separately:
- Discovery: 15 entries return matches, such as searchProducts in E-Commerce, example 01, and findNearestServiceCenter in Government and Public Services, example 02.
- Retrieval: 29 entries return an existing item, record or status. Examples include getProductDetails in E-Commerce, example 03, and getEnrollmentStatus in Education and Learning, example 03.
- Calculation, comparison or assessment: 17 entries derive an answer from inputs or fetched facts. calculateLoanEMI in Financial Services, example 01, and estimateDelivery in E-Commerce, example 08, belong here. Classification does not validate the underlying formula or decision rule.
- Content generation or transformation: five entries produce content, including generateQuiz in Education and Learning, example 06, and translateArticle in Media, News, Publishing, example 07. Whether generation also stores or refreshes records needs a separate check.
- Display or session change: two entries alter what subsequent interaction uses. showProducts in E-Commerce, example 02, changes the displayed grid; applyDietaryFilters in Food Delivery and Restaurants, example 10, changes session defaults.
- Workflow or record change: 32 entries create, modify, submit or trigger something. initiateReturn in E-Commerce, example 10, and submitAssignment in Education and Learning, example 05, have different consequences, despite sharing this category.
These are counts of catalogue entries, classified by their intended primary result. The catalogue has 97 distinct tool names: addToCart, applyCoupon and trackOrder each appear in both the e-commerce and food sections. A repeated name can have different inputs and meaning. Conversely, different names can express related tasks. Neither 100 entries nor 97 names establishes a count of unique business tasks, tested APIs or deployed tools.
The separate access column matters as much as the category. getEnrollmentStatus returns a logged-in student’s progress, while getProductDetails describes a catalogue item. Both are retrieval examples. A functional label alone cannot tell an engineer which data the requester is allowed to receive. Similarly, a POST request can compute a read-only answer, and a session-setting tool can change later results without placing an order.
Select a task before copying a registration
Consider a fictional homewares retailer. A shopper wants to check an existing order, start a return for a delivered damaged line and assess delivery of a replacement product. Assume the retailer has a public product catalogue and an estimator for delivery to an Indian pincode, or postal code. Its order endpoints accept a signed-in session, but no per-order ownership enforcement has been demonstrated. These are invented conditions for this example, not a client case.
Four entries in Appendix B’s E-Commerce section fit parts of that request. The decision index selects two for proposed initial adaptation and defers two:
- Example 03, getProductDetails: select. The printed required input is productId. The proposed result is the identified product’s specifications, variants and stock, without accessing an original order.
- Example 08, estimateDelivery: select. The printed required inputs are productId and pincode, with a six-digit pincode pattern. The proposed result is a replacement delivery estimate, not an order reservation.
- Example 09, trackOrder: defer. The printed required input is orderId, but the description refers to one of the user’s orders. The missing ownership check prevents exposing its tracking data merely because a session exists.
- Example 10, initiateReturn: defer. The printed required inputs are orderId, lineId and a reason from a defined set. Ownership is still missing, and a return additionally requires eligibility and an authorized state change.
With ownership enforcement still unverified, a four-tool plan would conceal an unresolved private-data boundary. The narrower two-tool proposal can support replacement planning; it cannot complete the original-order or return request. Establishing and verifying order ownership could bring tracking back into scope. It would not, by itself, establish that return submission is ready.
Adapt the inputs and result boundaries
For product details, bind productId to an authoritative catalogue record and specify what happens for an unknown product. For delivery estimation, pass that same product identifier and the destination pincode. The proposed acceptance check compares returned product, variant and stock with known catalogue fixtures, then compares serviceable and unserviceable destinations with the shipping service’s expected responses. Invalid destination input must not produce a plausible delivery promise. Neither tool should change a cart, order or return.
Authenticated tracking needs a different prerequisite. The server must determine that this actor may read this particular order. OWASP’s authorization guidance calls for permission checks on every request and on the specific object being accessed. A proposed test would compare an allowed own-order response with its shipment record, then try a second account’s order identifier and an expired session. Those negative cases must reveal no tracking or personal data. An order identifier supplies a lookup key, not permission.
Return initiation adds a business-state boundary. The line must belong to the permitted order and be eligible under the retailer’s actual return policy. The shopper should confirm the specific line and reason before submission. Proposed checks would establish that declining creates no return, confirming an eligible request creates one matching return, and repeating the submission creates no second return. The observable result is the saved return reference tied to the intended order and line. A successful callback alone would not establish it.
These checks are proposed acceptance conditions. The catalogue inspection did not invoke the retailer’s APIs, register browser tools or create a return. It also did not establish a return window, refund entitlement or shipping commitment. Those business rules must come from the application being adapted.
Check the current API before adapting the code
The source registrations use navigator.modelContext.registerTool. Chrome’s Imperative API documentation, updated 16 October 2026, instead shows document.modelContext.registerTool. Its execution callback receives cancellation options containing a signal. The catalogue’s return example uses a client.requestUserInteraction callback, while the current draft defines an options object containing an AbortSignal. Treating the printed callback as a current interface would skip a material compatibility check.
The useful lesson survives that syntax difference: describe the task precisely and preserve user control over consequential actions. The current Chrome security guidance recommends readOnlyHint for tools that do not change state and consequentialHint for significant or non-reversible actions so an agent or browser can request confirmation. It also warns that read-only tools can expose user information. An annotation does not establish the retailer’s order ownership checks or return authorization.
For this case, keep the product and delivery examples as candidate shapes, then adapt them to a declared browser implementation and the retailer’s actual endpoint contracts. Define the return confirmation and execution boundary against that implementation before revisiting the deferred action. The decision index records the source example and the required adaptation separately, so a later API change does not erase why a task was selected.
Give the index and the implementation different proof
In Chapter 12, “The 90-Day Playbook”, Hardik Shah and Vidyadhar Shirke write in WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” Applied here, the first deliverable is the completed catalogue index and its two selected, two deferred decisions. That is documentary work. Shipping the two tools would need separate implementation and task evidence.
A proposed technical owner could use the index to define a bounded implementation: product details and replacement delivery estimation, with no private-order access. The next evidence would include the chosen browser build, registration version, inputs, outputs and the application records used for comparison. Chrome DevTools documents invocation status, input and output, but its manual tool testing can bypass the agent’s decision logic. A direct call check and a complete shopper-task check answer different questions.
The full shopper task remains incomplete until tracking and returns satisfy their own prerequisites. This preserves the practical consequence of the founders’ quotation: a completed inventory is not counted as a shipped return workflow. A future implementation record must show the particular deliverable it establishes.
Where ScaleGrowth’s capabilities fit
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of experience in organic growth marketing and undertakes pioneering work in AEO and GEO technology. For this catalogue-selection problem, the relevant capabilities are AgenticReadiness audit systems, OGOS, the Organic Growth Operating System, for on-page requirements and content briefs, and WebMCP implementation and consulting.
Those capabilities address distinct parts of the work: identify which existing tasks deserve exposure, write descriptions and requirements that match them, and adapt the chosen tools to the application. They do not establish that every named system is integrated or that the fictional retailer’s missing authorization has been solved. The useful starting scope is the completed decision index, followed by the specific ownership work needed before expanding the subset.
ScaleGrowth Digital publishes this article and provides the audit and implementation services discussed here. The decision index establishes what was classified and selected. It provides no deployment evidence or independent assessment of the provider. For the fictional retailer, the immediate selection remains two replacement-planning candidates, with order tracking and return submission deferred for stated reasons.
References
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Chrome Imperative API
https://developer.chrome.com/docs/ai/webmcp/imperative-api
Chrome WebMCP tool security
https://developer.chrome.com/docs/ai/webmcp/secure-tools
OWASP Authorization Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
Chrome DevTools: Debug WebMCP tools
https://developer.chrome.com/docs/devtools/application/webmcp