WebMCP React

Choose one workflow

React teams should begin with a workflow that already works for people: product lookup, support search, quote preparation or appointment availability. A WebMCP tool should describe a narrow capability with a useful result, not expose every visual control. Write the goal, inputs, output and failure states before writing registration code. This makes the tool easier to explain to an agent and easier for a human to test.

Use the current browser surface

The current documented imperative surface is document.modelContext. Feature-detect it in the browser and register a tool with a stable name, description, inputSchema and execute function. Keep the ordinary React UI available when the API is absent. Treat navigator.modelContext only as a legacy compatibility signal, and do not describe a static code reference as runtime support.

Design inputs as a contract

Use explicit JSON Schema properties, types, formats, descriptions, required fields and additionalProperties: false where appropriate. For React, map agent input into the same validated application action used by a person. Never trust a string because it came from an agent, and do not use hidden component state or a client-only disabled button as authorization.

Separate preparation from commitment

Search and lookup are often read-only. Cart preparation or draft quote data may be reversible. Booking, checkout, order submission, account changes and identity workflows can create commitments or affect sensitive data. Mark the consequence, show the final values, require an explicit human confirmation and enforce authorization on the server. WebMCP should reduce friction without bypassing consent or security.

Test lifecycle and failure states

A real implementation must survive route changes, hydration, re-rendering, duplicate mounts, network errors, rejected validation and cancellation. React integration code should clean up registrations where the API supports it and should not leave stale handlers after navigation. Test keyboard access, labels, loading, error and success states in the same page a person uses.

Move from guidance to verification

Use the WebMCP Generator for a starting schema, the Validator for static checks and the Simulator for task-to-tool mapping. A controlled browser test is still required before calling a tool Verified. For a production rollout, involve the implementation service when data, money or identity are involved.

Framework-specific delivery notes

In React, keep the schema and registration policy stable outside transient component state. Register from the client lifecycle, avoid duplicate names after a route transition, and connect execution to the same validated action used by the form. A pending state should be visible to the person, and an AbortSignal or equivalent cleanup should prevent stale handlers from updating an unmounted screen.

A practical test case

Give the implementation one deterministic test: a user asks for a useful read-only result, the agent supplies valid and invalid input, the page shows a loading state, the server authorizes the request, and the human can continue without WebMCP. Then repeat with a consequential action and verify that the final commit is blocked until confirmation. Record expected output, error text and cleanup behavior for react.

Connect the delivery path

Use Autopilot to prioritise the workflow, then the Generator, Validator and Simulator. The Implementation Service can review the production boundary.

Operational detail

Keep WebMCP registration close to the feature owner, but keep business rules in the existing service layer. A useful React test covers a fresh mount, a route change, a second mount in development and an unmount while the request is pending. Confirm that the tool disappears or is replaced when its page capability is no longer available, and that the visible form remains the source of truth for people.