WebMCP Explained: Should Your Website Expose Tools to AI Agents?

Chrome's WebMCP documentation describes web APIs through which a page can offer tools to an AI agent operating in the browser. A tool has a name and description that help an agent decide when it applies, an input contract that constrains arguments, and an implementation that produces a result. The central change is not that the website becomes autonomous. It is that a browser agent can inspect a purpose-built operation instead of reconstructing the same intent from a long sequence of UI observations. A travel site might expose a reversible search operation; a project product might expose create draft; a retailer might expose an add-to-cart preparation step. The surrounding browser remains important because it carries page context, the user's session, visible review state, and the human interaction boundary.^{1, 2, 3}

The official sources do not establish WebMCP as a universal compatibility layer for every current agent. They describe a proposed and evolving web capability, and Chrome's Lighthouse material checks a limited set of registration conditions. AgentReady therefore recommends progressive enhancement: keep the ordinary page understandable and operable with native links, buttons, labels, headings, and status messages; add a structured tool where it removes genuine ambiguity; and preserve the same authorization and consequence rules on both paths. If WebMCP is unavailable, the user should still be able to finish through the visible interface. If it is available, the tool should make the intent clearer without creating a privileged back door.^{4, 1, 5, 6, 7, 8}

The official Chrome guide presents two authoring approaches. The declarative path builds on HTML forms, allowing an applicable form to communicate tool-oriented metadata while retaining its normal browser behavior. This is attractive when the existing user journey is already a well-designed form: inputs are labeled, constraints are visible, validation is recoverable, the submit consequence is clear, and a result appears on the page. Search, filtering, quote preparation, or a non-destructive calculator are natural candidates. Declarative exposure should reward a sound form, not camouflage a weak one. Hidden requirements, placeholder-only labels, ambiguous submit text, and generic error messages remain problems for both people and agents.^{1, 2, 6, 7, 8}

The imperative path lets application code register a structured operation when a form is not an adequate model. It can represent multiple-stage computation, combine state already available in the page, or return a more explicit result object. That flexibility increases the maintenance burden. The tool description, input schema, server validation, UI state, and backend behavior must agree. A renamed plan, retired field, or changed permission rule can leave a plausible but stale tool behind. AgentReady recommends generating schemas from a shared domain contract where practical, adding ownership and a review trigger, and testing the deployed behavior rather than validating only a checked-in definition. OpenAPI or server-side MCP may remain the better boundary for operations intended to work independently of a webpage; WebMCP is most useful when browser and page context are part of the experience.^{1, 3, 9, 10}

A registered tool can be syntactically valid and still be a poor choice for an agent. Names such as process, continue, or submit provide little basis for selection. Descriptions should state the user-visible job, important prerequisites, and what the call does not do. Inputs should use narrow types, enums, formats, and required fields instead of a single free-form instruction. Read and write operations should not share an ambiguous tool. A search tool can return candidate IDs and current facts; a separate preparation tool can build a reversible draft; a consequential commit should identify the exact target and wait for the appropriate confirmation. The server must validate every argument because a schema helps selection and generation but does not confer trust.^{1, 5, 3, 9, 11}

Results need the same care. Return an explicit status, identifiers safe to expose, current state, validation problems, and a next step. Distinguish prepared from approved, accepted from completed, and failed from uncertain. For a retried write, use an idempotency strategy and tell the caller whether the original operation was found. Mirror the important result in the visible interface so the user can understand what happened. AgentReady recommends a durable receipt for any action that creates a record, changes state, sends something, books something, or initiates payment. The receipt is not merely convenient output: it is how a journey test avoids treating a disappearing spinner or optimistic toast as authoritative completion.^{3, 9, 11, 8}

A browser agent may operate in a session where the user is signed in, which makes a convenient tool materially different from a public metadata file. The page still needs to authenticate the actor, and the server still needs to authorize that actor for the exact object and operation. Never infer authority from the tool's presence, its description, page text, or a model's statement. Scope operations to the minimum capability, recheck ownership and tenant boundaries on every request, rate-limit abuse, and avoid returning secrets in errors or results. Consequential work should surface the target, effect, important values, and reversibility before execution and require fresh approval near the boundary.^{1, 9, 11}

The official WebMCP material keeps the user and browser permission experience central; AgentReady's additional recommendation is to treat that confirmation as one control in a larger chain, not as the authorization system itself. Test with a disposable tenant and synthetic data. Set an allowed-action list, prohibit production money and external communications, define a safe stopping point, and revoke access after the run. The safe post-sign-in testing guide provides that fixture model. An agent that refuses an unauthorized call or pauses at the declared review state has behaved successfully, even though it did not maximize the number of completed operations.^{1, 9, 11}

Structured syntax does not remove prompt injection or confused-deputy risk. A tool description can be misleading, page content can contain instructions aimed at an agent, retrieved text can be contaminated, and a result can ask for an unrelated follow-up. Agents and sites should keep untrusted content separate from system policy and user authorization. The site should validate target and arguments server-side, restrict origins and destinations, minimize privilege, and log the operation and outcome without copying sensitive content unnecessarily. Tool output should describe domain state, not issue open-ended behavioral commands to the agent. Security review must consider what happens when the tool is selected incorrectly as well as when the implementation is directly attacked.^{1, 9, 11}

AgentReady recommends adversarial fixtures alongside happy paths. Present two similarly named tools and verify that the agent chooses the safe one. Insert hostile text into an ordinary content field and verify that it cannot change the allowed action. Pass an object belonging to another synthetic tenant and require a server-side denial. Repeat a write with the same idempotency key and require one effect. Ask for an operation outside scope and require refusal or escalation. Capture the first unsafe ambiguity and the authoritative after-state. These are proposed testing practices, not claims about what Chrome's registration audit proves.^{9, 11, 10}

WebMCP should not become a reason to hide public facts or abandon established interfaces. Search and recommendation agents still need crawlable canonical pages with visible, current explanations. People and browser agents still benefit from semantic HTML and accessible state. Integrations that run without a page may need a documented API, OpenAPI contract, server-side MCP service, or another product-specific channel. Commerce flows may additionally depend on payment and order protocols, which the UCP, ACP, and MPP comparison treats as separate business boundaries. Choose the interface from the user goal and execution context, then keep the facts and permission rules consistent across them.^{1, 12, 2, 6, 3, 8}

A practical rollout starts with one frequent, bounded, reversible job whose browser context matters. Keep the visible path intact, add the smallest useful tool, and instrument selection, validation, user approval, server outcome, and receipt without storing prompts or secrets by default. Compare the tool-assisted path with the ordinary browser journey and watch for a new class of failure: a tool may be easy to invoke but harder for the user to understand. The Lighthouse Agentic Browsing explainer shows how to use deterministic registration checks without turning them into certification, while the readiness score versus journey success guide keeps implementation signals separate from observed outcomes.^{4, 1, 5, 9, 10}

Chrome's Lighthouse audit for registered WebMCP tools can identify deterministic issues in the applicable page-level setup. That is useful preflight evidence, but it does not show that an agent selected the intended tool, supplied correct arguments, respected a confirmation, handled an error, or produced the requested business result. Run the audit and preserve its individual findings. Then define a task card with starting URL, authenticated state, requested goal, allowed actions, prohibited consequences, safe stopping point, and success assertion. Pin the browser, agent surface, model or harness version when available, locale, viewport, fixture version, and date so later results are comparable.^{4, 5, 9, 10}

Execute the same task through the visible interface and the WebMCP-assisted path where supported. Record discovery, tool choice, argument construction, approval, execution, recovery, receipt, and independent state readback as distinct stages. Do not translate unsupported into failed, and do not translate one successful demo into universal support. The cross-agent website test methodology can keep fixtures stable across surfaces. Aggregate results belong in the Agentic Customer Journey Index only with consent, inclusion rules, dates, denominators, and limitations; comparative leaderboards need the same published methodology before any ranking claim.^{9, 10}

The available AgentReady public diagnostic inspects prerequisites around a candidate page: reachability, content, semantics, browser stability, forms, and safety signals. The available WebMCP Preflight then parses a supplied registration document locally and checks names, descriptions, object schemas, input constraints, consequence clarity, harmless-test declarations, authorization language, and declared human-form parity. It does not read a live browser registration, invoke an operation, confirm that a declaration is true, or explain a Lighthouse report. Its output is bounded contract evidence, not an unsupported universal grade.^{4, 1, 5, 6, 3, 9}

A Safe Tool Journey Runner remains proposed. A site owner would attach a disposable tenant, define an allowlist and safe stop, choose a supported browser surface, and run a versioned task. The runner would capture sanitized evidence for selection, arguments, permission prompts, validation, result, and independent after-state; refuse undeclared origins and production credentials by default; and label unsupported capabilities separately. Together, the scan, preflight, and future runner create a product-led path from news to implementation: learn what WebMCP changes, scan the public page, repair the supplied contract, test one controlled outcome, and publish only consented evidence.^{9, 11, 10}