A search tool can promise that returned items match stated filters. A recommendation tool must also explain the basis for preferring an item for a purpose. Returning the cheapest matching product answers a price preference; it does not, by itself, establish that the product is suitable for the job.
That distinction belongs in the tool contract: the inputs accepted, the result returned and the meaning the application assigns to that result. If the catalogue supports retrieval but lacks the evidence needed for suitability, expose retrieval. Add a preference ordering only when its criteria are explicit. Do not let a name such as recommend_product quietly enlarge the promise.
One catalogue, three different questions
Consider a fictional retailer of task lights. Its product team wants an assistant to find lights and recommend one for judging paint colours. The catalogue records price, light output and stock status, but has no colour-accuracy evidence. This missing field changes the decision: the team can implement a filter and a declared price preference, but cannot substantiate the requested colour-matching recommendation from those records.
The following synthetic inventory is the complete catalogue used in a local demonstration. Prices are invented integer minor units, not offers in a real currency. Lumens are fixture values for light output, not measurements of actual products. Every item has colour_accuracy_evidence set to null.
- A: price_minor 6000; lumens 800; in_stock true.
- B: price_minor 4500; lumens 600; in_stock true.
- C: price_minor 4500; lumens 400; in_stock true.
- D: price_minor 4500; lumens 600; in_stock true.
- E: price_minor 4000; lumens 900; in_stock false.
- F: price_minor 5000; lumens null; in_stock true.
Use the same filters for the three main requests: {“max_price_minor”:6000,”min_lumens”:600,”in_stock”:true}. The price ceiling and light-output floor are inclusive. Unknown light output fails the floor rather than being guessed. A, B and D match; C is below the floor, E is out of stock and F lacks the required value.
The requests below were manually labelled and expressed as typed JSON. The demonstration does not extract intent from arbitrary natural language. Each request also carries a string request_id so its response can be compared with the corresponding expected result.
- Descriptive request S1: tool “search”, with the common filters. It asks which records meet the stated conditions.
- Preference request R1: tool “rank_preferences”, with the common filters and preferences [“price_ascending”,”lumens_descending”]. It asks for lower price first, then higher light output.
- Suitability request U1: tool “assess_suitability”, with the common filters and purpose “colour_matching”. It asks whether the records support that specific use.
Compare the promises, not just the schemas
All three requests can contain valid fields while making different demands on the application. A schema can describe a purpose field without supplying evidence that any product meets that purpose. The contract must connect the response to what the underlying data and decision rule actually establish.
- Search contract: accept typed filters; return matching IDs and basis “filters_only”. Alphabetical ID order is a display choice, not a quality ranking. Promise an exact match against this snapshot, not the best product.
- Preference contract: accept the filters and the declared preference order; return ordered IDs, shared ranks and the ranking basis. Promise ordering under those preferences, not suitability for paint-colour assessment.
- Suitability contract: accept the filters and a supported purpose; require evidence relevant to that purpose before returning an affirmative assessment. Here the only supported result is “insufficient_evidence”, with the missing field named.
For R1, the rule is lexicographic: compare price first and light output only when price ties. There are no weights or weighted scores. B and D share rank 1 because both values tie; A has rank 3. Alphabetical ID order places B before D on screen but does not make B preferable to D. This treatment prevents an arbitrary display order from becoming a false recommendation.
These are deliberately narrow contracts. An explicit minimum light output is a retrieval constraint, not proof that the light is adequate for every workspace. Nor does a lower price establish better value. For the fictional colour-matching request, the missing colour-accuracy evidence cannot be replaced by a brightness value or by the assistant’s confident wording.
Return the boundary in the response
A descriptive response can be short and precise: {“request_id”:”S1″,”status”:”matches”,”ids”:[“A”,”B”,”D”],”basis”:”filters_only”,”recommendation”:false}. Its prose equivalent is: “A, B and D match the price, light-output and stock filters.” Calling them the best lights would add a judgement that this result did not compute.
The preference response is: {“request_id”:”R1″,”status”:”preference_order”,”items”:[{“id”:”B”,”rank”:1},{“id”:”D”,”rank”:1},{“id”:”A”,”rank”:3}],”basis”:”price_ascending_then_lumens_descending”,”recommendation”:false}. A bounded explanation is: “B and D tie under your lower-price-first preference; A follows. This order does not assess colour matching.” The fixture calls this preference ordering, not a product recommendation.
For the evaluative purpose, the response is: {“request_id”:”U1″,”status”:”insufficient_evidence”,”ids”:[“A”,”B”,”D”],”missing”:[“colour_accuracy_evidence”],”recommendation”:false}. A useful explanation is: “These items match your filters, but this catalogue cannot establish which is suitable for colour matching.” That answer preserves the usable search result without inventing an assessment.
A fourth request, “Which is best?”, was represented by the same filters and preferences set to null. It returned “clarify_preferences” rather than silently choosing a ranking rule. Asking for the missing preference is different from asking for missing domain evidence: a user can state a price priority, but that statement does not create a product test.
What the completed local run establishes
The versioned demonstration, 0211-fixture-v1, ran on 17 October 2026 using Python 3.12.14 and its standard library on Linux. The complete inventory, typed requests and literal expected responses were frozen before the producer and separate evaluator were implemented. The evaluator compared submitted JSON with a separate literal oracle; it did not import the producer to calculate its expectations.
Six cases were replayed in two fresh command-line processes. Both replays matched all six expected responses and produced identical output bytes. Besides the search, preference, missing-preference and suitability cases, the suite checked an empty match set and a price ceiling supplied as a string. The latter returned “invalid_input”, not “no_matches”, because a malformed request is not evidence that the inventory lacks a match.
The evaluator also received three deliberately incorrect responses. It rejected a search response that admitted out-of-stock E, a preference response that put brighter A first and split the B/D tie, and a suitability response that recommended A without colour-accuracy evidence. Those controls show that the evaluator detected these particular contract violations. They do not establish that it catches every possible defect.
This is a deterministic application-contract demonstration, not a native WebMCP, browser or live language-model test. It establishes neither that an agent selects the intended tool nor that its final wording respects the returned boundary. No real products, customer deployment or ScaleGrowth system were tested. A separate evaluator is also not independent human validation.
Expose the task accurately, then test the agent separately
The WebMCP draft inspected on 17 October 2026 describes JavaScript tools with natural-language descriptions and structured schemas. Its 16 October draft is not a W3C Standard. Chrome’s guidance recommends precise action names, specific parameter types and validation in code. That supports describing these application functions according to their actual jobs; it does not turn a catalogue search into a suitability engine.
Names such as search_lights and rank_lights_by_declared_preferences would make the proposed distinction visible. Their descriptions should say positively what each returns: matching catalogue records, or a preference order under named criteria. A future suitability tool would need a defined purpose and adequate product evidence, not merely a more ambitious description.
Chrome DevTools documentation distinguishes manual invocation from an agent’s decision logic. That is a useful next-test boundary. In a proposed browser test, record the user request, selected tool, actual parameters, returned result and final answer. For the fictional paint-colour request, acceptance would require the assistant to preserve “insufficient_evidence” and avoid naming a suitable product. For the price preference, it would need to retain the B/D tie. These browser and agent tests have not been run here.
Build the evidence before widening the promise
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. It publishes this reference and provides WebMCP implementation and consulting, supported by a team with years of experience in organic growth marketing and pioneering work in AEO/GEO technology. AgenticReadiness audit systems are relevant to identifying which tasks need contract work. WebMCP consulting is relevant to defining the callable functions and testing their boundaries. Those capabilities fit a business that needs to separate discovery from evaluation; the local demonstration is not a measurement of those systems.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter IV, “What Brands Build Now”, of The Discovery Reset: “A quarterly industry benchmark with primary data nobody else has.” The passage concerns original research and the material published around it. Its practical consequence here is to retain the method and underlying record behind an evaluative claim, rather than reuse an unsupported conclusion. This walkthrough is a synthetic demonstration, not that industry benchmark or a claim to unique primary product data.
For the fictional retailer, the proposed intervention is to retain search, expose the price preference as a distinct function and defer an affirmative colour-suitability response. The implementation decision would change if relevant product evidence became available and a domain specialist established a defensible suitability method. An API architect should then review the contract, including missing fields, error states and ties. Those specialist reviews are proposed, not completed.
The immediate acceptance condition is observable: the same inventory produces filter matches, a declared preference order or an explicit evidence gap according to the requested task. Widen the tool’s promise only when the additional judgement has its own supported method and test, and keep agent selection and final-answer behaviour as separate checks.
References
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
WebMCP best practices
https://developer.chrome.com/docs/ai/webmcp/best-practices
Debug WebMCP tools
https://developer.chrome.com/docs/devtools/application/webmcp
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/
Solid-state lighting metrology
https://www.nist.gov/programs-projects/solid-state-lighting-metrology
CIE e-ILV colour rendering
https://cie.co.at/eilvterm/17-22-107