WebMCP gives a web application a way to expose a task as a tool with structured inputs and an execution callback. For product search, the useful result is a recommendation backed by the exact catalogue attributes that make an item suitable. A search for a table that fits an 80 mm storage gap succeeds only if the application and the assistant preserve what that measurement means.
The WebMCP draft (https://webmachinelearning.github.io/webmcp/) describes this tool interface. It remains a Community Group draft, not a W3C Standard. The folding-table example below uses an application-designed contract to explain the mechanism.
The product question: will the table fit when folded?
Illustrative synthetic catalogue, dated 16 October 2026: a customer needs a folding table for a room with limited storage. The request is, “Find an in-stock folding table at least 1,200 mm wide when open and no more than 80 mm thick when folded.” The catalogue records and product identifiers in this example are fictional. The input and response illustrate a proposed read-only tool, not a browser-agent replay.
The decisive distinction is between tabletop thickness and folded thickness. A table with a 30 mm top may still occupy 95 mm when its legs are folded underneath. Finding “30 mm” on its product page would not establish that it fits the storage gap. The search must use the dimension of the whole folded product.
The fixture contains three products. All three are described as folding tables and marked in stock, so neither the category name nor availability resolves the choice:
- FT-A: 1,200 mm open width, 70 mm folded thickness and 30 mm tabletop thickness. Its folded dimensions meet the storage requirement.
- FT-B: 1,200 mm open width, 95 mm folded thickness and 30 mm tabletop thickness. It is a plausible near-match, but its folded thickness exceeds the limit.
- FT-C: 1,400 mm open width and 30 mm tabletop thickness. Folded thickness is absent from the record, so suitability for the gap is unknown.
This is where a useful tool contract begins. It must represent the customer’s storage requirement explicitly enough that a search cannot satisfy it with the wrong dimension.
The tool contract preserves the meaning of each input
Call the fictional shop’s tool findFoldingTable. Its purpose is to return catalogue-backed candidates for a folding-table request. The operation reads product records; it does not reserve stock, add an item to a basket or place an order. Its description should make that scope clear before an assistant chooses it.
The input schema, which defines the permitted fields and their types, requires a category value of folding_table, an integer minOpenWidthMm, an integer maxFoldedThicknessMm and a Boolean stockRequired. The description of maxFoldedThicknessMm specifies the total thickness with the table folded for storage. These names are illustrative application fields, not prescribed WebMCP parameter names.
For this contract, a product qualifies only when its category matches, its open width is at least the requested minimum, its folded thickness is known and no greater than the requested maximum, and its stock flag satisfies the request. The application must validate the inputs before applying those comparisons. A missing folded dimension belongs in an unknown or excluded result, rather than becoming zero or being copied from tabletop thickness.
The response design matters as much as the inputs. A bare product identifier leaves the assistant to reconstruct why the item qualifies. Return the product identifier, the compared values, a link to the corresponding product record and the catalogue snapshot used. The same record must support both dimensions. Combining the width of one variant with the folded thickness of another would produce a recommendation that no listed product actually satisfies.
The invocation turns the request into one bounded search
For the customer’s request, the illustrative invocation is findFoldingTable with category = folding_table, minOpenWidthMm = 1200, maxFoldedThicknessMm = 80 and stockRequired = true. The tool’s execution callback applies the application’s search logic to those inputs and returns a response.
The designed response has status = ok and catalogueSnapshot = synthetic-2026-10-16. Its matches collection contains FT-A with category = folding_table, openWidthMm = 1200, foldedThicknessMm = 70 and inStock = true. It includes productPath = /products/FT-A and evidenceRefs = FT-A:dimensions and FT-A:availability. These fictional locators identify the product and the records supporting its dimensions and stock flag.
The response also identifies why the other candidates do not establish a match: FT-B has foldedThicknessMm = 95, which exceeds 80; FT-C has foldedThicknessMm = null, which means the required dimension is unknown. A separate nearMatches collection can preserve that information without placing either product in matches. These response labels and collections are choices in this example’s application design.
The assistant can now explain the choice in ordinary language: “FT-A meets the stated dimensions: it is 1,200 mm wide when open and 70 mm thick when folded. It is marked in stock in the example catalogue.” That answer carries the decision-changing evidence forward. Describing FT-B merely as another compact option would discard the reason it failed.
The tool has supplied a bounded catalogue answer. The assistant still has to choose the appropriate tool, preserve the requested values and describe the result accurately. A well-formed invocation alone cannot show that all of those decisions were correct.
The result needs a task check and an honest fallback
For this fixture, the observable acceptance condition is specific: the original request returns FT-A as the only verified match, and the assistant’s recommendation cites its 1,200 mm open width and 70 mm folded thickness from the same product record. FT-B must not be presented as fitting the gap, and FT-C must retain its unknown folded dimension. The search must leave the catalogue and basket unchanged.
A useful fallback follows directly from the same rule. If FT-A is removed from the fixture, the answer becomes “No verified match in this catalogue snapshot.” The assistant can explain that FT-B is too thick and FT-C lacks a folded measurement. It can offer to check FT-C’s product information or ask whether the customer can change the storage limit. It should obtain that change before running a relaxed search.
An empty result also needs to be distinguishable from a failed search. In this application design, no_match means the search completed without a verified candidate; invalid_request means the supplied fields failed validation; catalogue_unavailable means the search could not obtain the records. The WebMCP draft’s failure discussion (https://webmachinelearning.github.io/webmcp/) separates platform-defined execution failures from tool-author failures returned in response JSON. A retrieval failure should therefore not be translated into “the shop has no suitable products.”
Chrome’s WebMCP debugging documentation (https://developer.chrome.com/docs/devtools/application/webmcp) notes that manual tool invocation can bypass the agent’s decision logic. A direct call is useful for checking the callback’s response to chosen inputs. A task run must show whether the assistant selected the right operation, kept 80 mm as the folded limit and used the returned evidence correctly. Retain the request, input, output and resulting answer together so those decisions can be assessed.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. AEO means answer engine optimisation; GEO means generative engine optimisation. Its team has years of experience in organic growth marketing, and its capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting. For a catalogue task like this one, the practical work is to define the deciding product attributes, expose a read-only search operation and assess whether its result supports the customer’s choice.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 12 of WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” Applied to this example, an implementation engineer could own the read-only search sandbox, with completion defined by four required cases passing: the original request, removal of the valid product, an exact 80 mm boundary and a wrongly typed input. That proposed count gives the deliverable a concrete completion condition. Each case should assess the expected answer and unchanged application state, rather than count tool invocations.
If a catalogue contains only tabletop thickness, the folded measurement needs to be obtained before that product can be recommended as fitting the gap. WebMCP can carry precise evidence only when the product data contains it. ScaleGrowth Digital publishes this article and provides the implementation services discussed here.
References
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Chrome DevTools: WebMCP
https://developer.chrome.com/docs/devtools/application/webmcp
ScaleGrowth: Answer Engine Optimization (AEO)
https://scalegrowth.digital/services/ai-visibility/aeo/