WebMCP vs MCP: Same Tool Idea, Different Boundary
MCP usually connects an agent to a remote service. WebMCP exposes tools from the page already open in the browser. The difference changes state, authentication, discovery, and security.
WebMCP borrows the tool idea people know from the Model Context Protocol, but the two are not interchangeable.
An MCP server usually lives outside the page. It may run on a developer's machine, behind an API, or as a hosted service. An agent connects to it, lists its tools, and calls them over a protocol transport.
WebMCP lives in the active web page. The page registers tools through document.modelContext, and a browser mediates calls from an agent that can see that page.
That sounds like a small implementation detail. It changes most of the operating model.
The practical comparison
| Question | MCP | WebMCP |
|---|---|---|
| Where does the tool run? | In a local or remote MCP server | In the active browser page |
| How is it discovered? | The agent connects to a configured server | The agent visits the page and asks the browser |
| What state is close at hand? | Server and integration state | Current page, visible UI, and client-side app state |
| Typical job | Query a service, repository, database, or control plane | Operate the website the user is currently viewing |
| Main interface | Protocol transport and server implementation | document.modelContext and annotated forms |
| Does it replace authorization? | No | No |
The WebMCP Community Group draft says a WebMCP page can be thought of as an MCP server whose tools are implemented in client-side script. That is a helpful analogy, as long as you do not mistake the page for a conventional network server.
Why page state matters
Consider a 3D editor. A remote MCP server can store models and run rendering jobs, but it may not know which object the user selected five seconds ago or which camera angle is on screen.
A WebMCP tool can read that state from the application and update the same canvas the user is watching. In OpenAI's WebMCP demo, Codex and the user work on the same model. Codex can modify the scene and capture views without taking over the user's visible camera every time.
This is where WebMCP earns its name. The model context is the live page, not a stale reconstruction of it.
Discovery works differently
Remote MCP servers are configured ahead of time. Once connected, their tools may be available regardless of which website is open.
WebMCP tools appear only after the agent reaches the page. Chrome lists this as a current limitation: an agent cannot know that a site has tools until it visits.
That makes WebMCP a poor replacement for a general account-management or infrastructure server. It is a good fit for actions tied to a particular interface and its current state.
AI Pass uses both boundaries
AI Pass has an authenticated remote MCP endpoint for project setup. A coding agent can use it, after user-approved device authorization, to inspect setup context and provision public app configuration. Those tools belong to the control plane.
The browser SDK's AiPass.webMcp API serves a different job. It lets an app expose actions such as "draft this caption" or "search this catalog" from the page. Those actions belong to the product interface.
The remote MCP endpoint does not appear in document.modelContext. Browser WebMCP does not receive the setup grant. Keeping the boundaries separate prevents a page tool from quietly inheriting control-plane authority.
When to use MCP
Use a remote MCP server when the agent needs capabilities that should exist independently of a page:
- repository or issue-tracker operations
- database queries
- deployment and infrastructure controls
- project provisioning
- private server workflows
These tools need their own authentication and authorization. A browser tab should not be the only thing keeping them alive.
When to use WebMCP
Use WebMCP when the action belongs to the current page:
- fill and submit a visible form
- change a canvas or editor
- navigate within a complex application
- run a diagnostic and display the result in the UI
- operate on the item the user currently selected
Keep the ordinary button, form, or keyboard path. The WebMCP tool is another invocation channel for the same product action.
When both make sense
A coding platform might use remote MCP tools to create a project and WebMCP tools to operate its in-browser editor. A travel service might use a remote server for account-level itinerary data and WebMCP for the booking form in front of the user.
AI Pass follows the same split. An agent can use the integration skill and remote setup tools to add AI Pass to a project. The resulting app can use WebMCP so a browser agent can operate a small set of app-specific actions.
AI Pass keeps those jobs separate. Remote MCP provisions and configures the project. WebMCP exposes only the page actions that the finished app intentionally supports.