WebMCP Architecture Diagram: How Browser-Native AI Agents Work (2026)

WebMCP (Web Model Context Protocol) is a browser-native standard, jointly developed by Google and Microsoft and published under the W3C Web Machine Learning Community Group, that lets websites expose structured, callable actions directly to AI agents running inside the browser. Instead of an agent inferring intent from screenshots, DOM scraping, or blind clicking, a WebMCP-enabled site publishes a Tool Contract — a machine-readable list of the actions it supports — that the in-browser agent can call directly, on the live, authenticated page.

Where server-side MCP connects an AI host to external tools and data sources over stdio or HTTP+SSE, WebMCP moves the same idea into the browser tab itself: the website is the server, the browser's AI agent is the client, and the "transport" is a JavaScript surface rather than a network connection. As WebMCP support lands in Chrome and Edge, architecture and product teams need diagrams that explain this new surface to engineers, security reviewers, and stakeholders. This guide covers the core components and includes ready-to-use prompt templates.

Why WebMCP exists

Before WebMCP, browser-based AI agents (browser extensions, agentic copilots, autonomous shopping or research assistants) had to interact with websites the same way a human does: parsing the rendered DOM, guessing which button does what, and clicking through multi-step flows. This approach is slow, brittle to UI changes, and can misfire on destructive actions like submitting a payment or deleting data.

WebMCP flips the model. A website that wants to be agent-friendly declares its capabilities explicitly — "add to cart," "apply this filter," "submit this form" — as typed, callable tools. The agent reads the Tool Contract, understands exactly what parameters each action needs, and calls it directly. This is the same shift MCP made for backend tool-calling, applied to the front end.

Core components of a WebMCP architecture

Tool Contract

The Tool Contract is the structured manifest a page publishes describing the actions it supports — each with a name, description, and typed input schema (similar in spirit to an MCP server's tool manifest). The agent fetches or receives this contract when it loads the page and uses it to decide which action fulfills the user's request.

Declarative API

For simple, static content — forms, buttons, standard e-commerce flows — sites can expose tools via HTML attributes on existing markup. This requires no JavaScript changes and lets an agent discover "add-to-cart" or "submit-form" actions directly from the page structure.

Imperative API: window.AICommands

For dynamic, stateful interactions, sites register tools programmatically through a JavaScript surface (window.AICommands). This lets a single-page app expose actions that depend on current client-side state — a filtered search, a multi-step checkout, an in-progress editor session — that the Declarative API can't capture.

In-browser agent

The agent itself runs inside the browser (as a browser feature, like Chrome's early preview, or as an extension) and acts on the live, authenticated session — it inherits the user's cookies and login state rather than needing separate credentials. This is the key architectural difference from server-side automation: the agent operates with the same permissions and context the user already has open in that tab.

WebMCP vs. server-side MCP

In production, the two are complementary: a shopping agent might use server-side MCP to query a price-comparison API while using WebMCP to actually execute the checkout on the retailer's own site, inheriting the user's logged-in session rather than needing stored credentials.

Prompt templates for WebMCP architecture diagrams

E-commerce site with WebMCP checkout

Hybrid WebMCP + server-side MCP research agent

What a good WebMCP diagram must show

• Tool Contract boundary: Which actions the page has explicitly published — not every button on the page is agent-callable, only declared tools
• Declarative vs. Imperative: Label which tools come from HTML attributes and which are registered via window.AICommands, since they have different update and testing implications
• Session inheritance: Make explicit that the agent acts with the user's existing authenticated session — this is the biggest trust boundary difference from server-side automation
• Destructive action guardrails: Flag tools that trigger irreversible actions (payment, delete, publish) so reviewers can verify confirmation steps exist
• Cross-tab or cross-site flows: If the agent orchestrates across multiple open tabs, show each site's Tool Contract as a separate node

Frequently asked questions about WebMCP architecture

What is WebMCP?

WebMCP (Web Model Context Protocol) is a browser-native standard that lets websites publish a structured list of callable actions — a Tool Contract — so AI agents running in the browser can act on the page directly instead of interpreting the visual UI. It was jointly developed by Google and Microsoft and published under the W3C Web Machine Learning Community Group.

How is WebMCP different from MCP?

MCP connects an AI application (the host) to external tools and data sources — typically backend servers — over stdio or HTTP+SSE. WebMCP exposes tools directly from a web page to an in-browser agent, with no separate server process and no separate credentials: the agent acts within the user's existing authenticated browser session. The two protocols are complementary rather than competing.

Should I diagram WebMCP integrations separately from my backend architecture?

Yes. Because WebMCP tools execute client-side with the user's live session, they carry a different trust and security model than backend MCP tool calls. Keep WebMCP tool contracts in a distinct layer of your diagram, and clearly flag any tool that performs a destructive or financial action so it gets appropriate review.

Related guides: MCP architecture diagram, A2A protocol architecture, agent payment protocols, and AI agent architecture diagrams.