Implementer note: same-core decision tool + Inspector NL→enum mapping #263

We exposed one existing client-side capability through the WebMCP imperative API on a live public page. This is a bounded early implementer experiment — one scenario, small sample — not a claim that WebMCP is a W3C Standard, is widely adopted, or is discoverable without visiting the page.

What we exposed

Tool: create_pilot_decision_record
Page: https://deliveringtogether.co.uk/tools/pilot-readiness-review/

The page is a Pilot Readiness Review: structured enum inputs, no free text, nothing stored. The tool calls the same validatePilotReadinessInput and createPilotDecisionRecord functions as the human form. Visible UI, business rules, catalogue, and persistence were not changed. There is no backend, public API, or MCP server. Unsupported browsers no-op.

Why the architecture was small

The judgement engine was already protocol-neutral (enums, validation, a deterministic record). The adapter derives inputSchema from those enums and registers via document.modelContext.registerTool. There is no second copy of the rules. That is closer to the explainer’s “reuse existing client-side code” goal than wrapping the DOM form.

What we observed

Same natural-language brief:

• Webpage UI path: 3 attempts; eventual correct recommendation 3/3; one first-pass navigation miss; on the order of 10 UI actions when it succeeded.
• Direct structured tool invocation: 3/3.
• Official Chrome Model Context Tool Inspector (reported model gemini-3.6-flash): selected this tool from a natural-language prompt only, with no DOM form actuation.

Deterministic tests: 37 passed / 0 failed. Independent technical review of the adapter (Gemini 3.7 Flash High): no material findings. We did not join the origin trial.

This does not show statistical superiority, universal agent reliability, all-scenario mapping correctness, user demand, SEO benefit, or that every site function should be a tool. Chrome’s docs already note that clients must visit the site to know tools exist.

Inspector NL→enum mapping

The prompt used the ambiguous phrase “first commercial-model pilot”. The Inspector chose pilotType = commercial-model-pilot (the hyphenated enum) rather than a looser token such as first-pilot. It also mapped:

• primaryProofArea = willingness-to-pay-commercial-viability
• participantSelection = hand-picked
• pricingCondition = free-discounted-sponsored
• supportLevel = high-touch
• scaleVolume = tiny-controlled
• outcomeTracking = not-tracked

The existing engine then returned severity invalid-claim (“Not valid for this claim as designed”) with blockers for discounted pricing and hand-picked participants — the same result the webpage would give for those enums.

Questions for WebMCP designers

1. Are read-only decision-support tools (structured judgement, not booking/checkout) useful as examples? Public demos we have seen are mostly commerce and UI actuation.
2. For enum-heavy tools, should per-const title / description in inputSchema be treated as the primary NL mapping surface? This Inspector run succeeded from schema text, not from a cheat-sheet.
3. We returned a structured recommendation object as JSON from execute, without outputSchema (see Introduce outputSchema (was: Should output also have a schema?) #9 / Add outputSchema to ModelContextTool and RegisteredTool #254). Would an output schema help this class of deterministic result?

Happy to move any of these onto an existing issue if that is a better home.