The simple version
A website already understands actions such as adding a layer, moving a calendar event, filtering a table, or exporting a video. Without WebMCP, a browser agent may have to infer those actions from pixels and page elements, then imitate a person clicking and typing.
With WebMCP, the page can present selected actions as named tools with plain descriptions and structured inputs. An agent connected to the page discovers the available tools, calls the right one, and receives a result. The website’s own code still performs the work.
You + AI agent
WebMCP tools
Live web application
What it unlocks
Shared live work
The agent changes the document, board, or timeline you have open. You see the result immediately, adjust it yourself, and let the agent continue from the new state.
Reliable actions
A tool such as move-layer or find-availability is clearer and less brittle than guessing where to click from a screenshot.
Capabilities on arrival
When the user opens a capable site, the agent can discover tools that match the current page and signed-in state. The URL becomes an address for abilities as well as content.
Existing product logic
A team can register JavaScript actions the application already uses, and a proposed declarative approach can describe suitable HTML forms.
WebMCP and regular MCP are complementary
They share the idea of tools: named capabilities with descriptions and structured inputs. But they are designed for different places. WebMCP takes inspiration from MCP; it is not simply the full MCP protocol running in a tab.
| Regular MCP | WebMCP | |
|---|---|---|
| Where it lives | A separate local or remote server connected to an AI application. | Inside the open web page, mediated by the browser. |
| What it is best at | Backend data and actions that should work without a particular page being open. | Client-side actions tied to the page, its interface, and its current state. |
| Typical experience | Ask the agent to use a connected service and receive a result. | Work with the agent in the same visible application and take over at any time. |
| Connection model | The AI client communicates with an MCP server through MCP transports. | The browser exposes a web-native API with origins, page lifecycle, and browser permissions. |
A product may benefit from both. Its MCP server could support cross-product or unattended workflows, while WebMCP makes the open product collaborative. Both can reuse the same API, authentication, business rules, and carefully chosen product capabilities.
Why shared state matters
Consider a design canvas. The page could expose tools for inspecting layers, creating components, arranging objects, and exporting files. You ask the agent to draft a landing page and watch it appear. Then you drag the headline, reject one variation, and ask the agent to continue.
There is no separate “agent version” of the design. You use the visual controls; the agent uses structured tools; both change the same document. Vision and ordinary browser automation remain useful for judging visual results or handling anything the page has not exposed, but they no longer need to be the primary control method.
A WebMCP tool call, step by step
- 1
The page registers tools
Each tool has a name, description, input schema, and code that performs the action.
- 2
The agent discovers and calls one
The browser mediates access and passes structured arguments to the selected tool.
- 3
The page does the work
Its existing client-side logic updates the application and returns a result to the agent.
What product teams need to decide
- Expose outcomes, not every internal function. A small, understandable toolset helps the agent choose correctly.
- Keep authorization in the product. A tool must honor the signed-in user, origin boundaries, and the same business rules as the visual interface.
- Separate reading, preparing, and acting. Risky or irreversible changes need clear review and confirmation.
- Treat page content as untrusted input. Agent instructions, tool descriptions, and application data require defenses against prompt injection and unintended disclosure.
- Design for interruption. The user should be able to see what changed, stop work, undo where practical, and continue manually.
Experimental as of August 2026
Promising, but not yet a stable web standard.
WebMCP is a Draft Community Group Report and its API can change. Chrome 149 offers a time-limited origin trial, and Microsoft lists a WebMCP origin trial for Edge. It is a good time to prototype a focused workflow, test the security and user experience, and avoid treating today’s API shape as permanent.
Sources and further reading: the WebMCP Draft Community Group Report, its official explainer and repository, Chrome’s origin-trial announcement, and Microsoft Edge Origin Trials.
Where to start
Choose one task where the user benefits from watching and steering the agent.
Map the application state, product actions, permissions, confirmations, and recovery path before exposing the first tool.
Explore the right MCP approach with Strata →