WebMCP Explained: How to Build an Agent-Ready Website

WebMCP is a proposed browser standard that lets a website expose structured tools to an AI agent instead of forcing the agent to guess which buttons to click. The current design offers declarative and imperative APIs, JSON-style input schemas and access to live page state. Chrome documents WebMCP as experimental: an origin trial is available from Chrome 149, and the API is still under active discussion. The practical opportunity is clear, but teams should treat it as a progressive enhancement—not as a replacement for backend APIs or a finished security boundary.

What WebMCP changes

A conventional browser agent inspects a page, infers the meaning of controls and simulates clicks or keystrokes. Small UI changes can break that workflow. WebMCP lets the site declare capabilities such as search_products, get_order_status or submit_application, with a description and a structured input schema.

Chrome’s WebMCP documentation identifies three useful properties:

Discovery: the page registers tools that an agent can inspect.
Structured inputs and outputs: schemas make parameters and expected results explicit.
Shared state: the tool runs against the page and session the user is actually viewing.

The result is not an invisible API detached from the interface. Tools execute on the webpage, so the user can see the site’s normal experience while the agent performs a defined action. That preserves the application’s own UX and reduces the number of interpreted steps.

WebMCP is not a replacement for MCP

WebMCP and the Model Context Protocol (MCP) solve related but different problems. Chrome’s comparison guide describes MCP as a general connection between an AI application and external data, tools or workflows. WebMCP is a proposed browser API for a live website and the browser agent operating in that tab.

Question	MCP	WebMCP
Where does the capability live?	Usually in a server or service layer	In the live web page and browser context
Availability	Persistent and platform-agnostic	Ephemeral and tab-bound
Primary job	Expose tools, data and workflows	Make an existing website understandable and actionable to a browser agent
Typical interaction	Background API call or resource lookup	Search, form completion or navigation on the visible site
Main boundary	Server authentication and authorization	Browser origin, page state, permissions and user session

The strongest architecture can use both. Keep core business logic, identity and durable workflows behind normal services or MCP. Add WebMCP where a browser-based user benefits from an agent interacting with the live, human-facing interface. SignorCrypto’s MCP vs A2A guide covers the wider distinction between tool access and agent collaboration.

The two WebMCP APIs

Declarative API for standard forms

The declarative path annotates standard HTML forms so the browser can expose common actions without rewriting the whole interface. It is a sensible starting point for search, filters, support requests, applications and other flows that already have clear form semantics.

The advantage is incremental adoption: a team can improve an existing human-first flow while keeping the form usable without an agent. The constraint is equally important: declarative tools fit predictable form interactions, not every complex state machine.

Imperative API for dynamic workflows

The imperative API uses JavaScript and document.modelContext.registerTool() to define richer tools for navigation, state management and custom application logic. A registration includes a name, description, input schema and an execute function. Optional annotations can indicate whether a tool is read-only, returns untrusted content or produces consequential side effects.

This API is more flexible, but it also creates more responsibility. The execute function must validate inputs, enforce the current user’s authorization and return concise, machine-readable results. A schema makes intent clearer; it does not make an unsafe function safe.

Security controls belong in the tool design

WebMCP can reduce accidental UI misinterpretation, but it does not solve indirect prompt injection. Chrome’s security guidance states that model-level defenses cannot guarantee safety inside a probabilistic language model. Page content, user-generated text and externally sourced data may contain instructions that attempt to redirect the agent.

Use the API’s safety hints and conventional application controls together:

Mark read-only tools with readOnlyHint and consequential actions with consequentialHint so the client can apply appropriate confirmation behavior.
Mark outputs containing comments, reviews or external data with untrustedContentHint.
Keep write tools narrow. Prefer submit_support_ticket with validated fields over a generic run_javascript capability.
Use exposedTo only for explicitly trusted origins when sharing tools across origins.
Keep authorization on the server and re-check it at execution time; the page is not a substitute for access control.
Show a meaningful confirmation before purchases, bookings, publication, deletion or data transfer. “Continue?” is weaker than a review of the destination and payload.

For the broader browser-agent threat model, see SignorCrypto’s practical security checklist for AI browser agents.

What builders should test first

Do not start by exposing every button on a site. Choose one workflow with a verifiable outcome and a clear owner, such as checking an order, filtering a catalogue or preparing a support request.

A pragmatic sequence is:

Map the user goal, required data and irreversible steps.
Expose a read-only tool first and measure whether the agent selects it correctly.
Define a strict input schema, short descriptions and bounded outputs.
Add write actions only after authorization, confirmation and rollback paths are explicit.
Test stale page state, missing fields, invalid values, navigation, cancellation and duplicate submission.
Log tool discovery, calls, denials, approvals, outputs and errors against the user session.
Compare WebMCP with the existing browser workflow and with a backend integration; keep the simpler option when it performs as well.

The quality of the context around a tool matters as much as the model’s raw capability. SignorCrypto’s context engineering guide explains how tools, memory and runtime data shape agent reliability.

Limits and rollout status

WebMCP is still experimental. Chrome’s documentation lists several boundaries that affect product planning:

A browser or agent must visit the site to discover its tools.
Tools are tied to the live page and session; they are not a persistent service by themselves.
The design is aimed primarily at local browser workflows with a human in the loop, not unrestricted headless automation.
Complex applications may need additional JavaScript and state refactoring.
The proposed API and browser implementation can change as the WebMCP community and implementers resolve open issues.

That makes a pilot appropriate, not a blanket migration. Treat WebMCP as an agent-facing layer over a well-designed application. Keep ordinary navigation, accessible forms, backend authorization and direct user control working when no agent is present.

FAQ

What is WebMCP in simple terms?

WebMCP is a proposed browser API that lets a website expose structured actions to an AI agent. Instead of guessing how to click through a page, the agent can discover a named tool with defined inputs and execute it against the current page.

Is WebMCP the same as MCP?

No. MCP is a general protocol for connecting AI applications to tools, data and workflows. WebMCP is a browser-focused proposal for exposing tools from a live website. They can complement each other.

Does WebMCP make a website safe for agents?

No. It improves interaction precision, but developers still need least-privilege authorization, validation, origin controls, meaningful confirmation, logging and prompt-injection testing.

Should every website implement WebMCP now?

No. Start with a narrow workflow whose outcome and permissions are easy to verify. Because the standard and implementations are experimental, use a progressive enhancement and retain a fully functional non-agent path.

Sources

If your team needs help turning an agent-facing web workflow into a secure product architecture, contact SignorCrypto for a concrete integration assessment.