A page can describe the actions it supports in a structured form an agent can discover and invoke—inside the browser, alongside the person using it.
A menu names what the kitchen can make and what choices the diner must provide. Nobody needs to inspect every appliance.
A website publishes named tools with descriptions and input schemas. An agent can choose a tool and supply structured arguments.
Uses the same visible web app and remains responsible for consequential choices.
Reads the page’s tool definitions and supplies the required arguments.
Executes JavaScript in the page’s authenticated, origin-scoped context.
The browser is the meeting place. The person, agent, page state, and application logic share one active experience.
The specification is still evolving, but several large platforms already cover different parts of the path from a website publishing a tool to an agent using it.
The desktop app’s built-in browser can discover and call WebMCP tools out of the box.
Every Liquid storefront publishes catalog, cart, checkout, and order-navigation tools.
Browser support is available through an experimental flag and origin trial.
An edge-injected bridge can add a WebMCP interface without changing origin code.
Infrastructure partners are funding examples, tooling, hosting, and the WebMCP Challenge.
The distinction matters: shipped runtime support, experimental browser support, and ecosystem sponsorship are different commitments—but together they create meaningful distribution.
search_flights.The agent interprets the rendered interface like a person. Flexible, but mistakes are easy.
The agent searches page elements and accessibility labels. Better signals, but still infers the workflow.
The site explicitly names the action, inputs, and implementation the agent should use.
WebMCP complements the human interface. It does not make clear labels, usable forms, or accessible design optional.
Find products matching a query and price ceiling.
{ "query": "desk lamp", "maxPrice": 80 }A form can declare its tool name, purpose, and parameter descriptions.
Complex or dynamic behavior can be exposed through document.modelContext.registerTool().
The proposal is evolving. The exact API surface can change while browser experiments and specification work continue.
Name, title, description, input schema, and behavioral hints.
A structured object containing only what the selected tool expects.
Data produced by page logic, returned to the calling agent.
WebMCP runs in the page. Unlike a typical backend MCP server, the tool can use current UI state and the user’s existing signed-in session.
A tool’s label cannot prove what its implementation will actually do.
A signed-in page may be able to purchase, publish, modify, or delete.
An over-specified schema can invite an agent to share unnecessary personal context.
Tool results can contain hostile or misleading content, including prompt injection.
High-consequence actions still need narrow scope, truthful descriptions, server-side authorization, visible review, and explicit confirmation.
Web teams have traditionally designed pages for people and APIs for software. WebMCP suggests a third surface: structured capabilities for agents working beside a person in the browser.
The durable decision is not “Should we add WebMCP everywhere?” It is: Which user goals deserve an explicit, bounded action—and what must remain visible and confirmable?
The agent acts in service of a goal, not merely because a tool exists.
Tools turn supported actions into explicit contracts.
Page state, authentication, and interaction remain close together.
Structured access improves reliability; it does not remove risk or responsibility.