Repository navigation
Prevent WebMCP from becoming a browser-dependent substitute for remote MCP #322
Description
Activity
- changed the title
[-]Risk of WebMCP becoming the conservative alternative to remote MCP[/-][+]Prevent WebMCP from becoming a browser-dependent substitute for remote MCP[/+]on Sep 26, 2026 Given a choice between exposing a BFF or service capability through remote HTTP MCP and registering a wrapper in the existing website, organisations will take the smaller, browser-centric change
I'm not sure I agree that WebMCP is the obvious, conservative first-step into the agentic world.
Requested change
- State that WebMCP is for capabilities whose meaning or state depends on the running browser client or shared UI session.
Is this not already clear from the repository? WebMCP literally requires a browser!
- Direct developers to expose browser-independent domain and service capabilities through remote MCP, even when the web UI also calls them.
This is probably something we can do more of, yeah. One question we get a lot is "should I just make my WebMCP tools a pass-through / proxy to my server-side MCP?".
So far, we think the answer is no, just like the web's existing JavaScript is not just a REST proxy. Making your site a REST proxy, or a server-side MCP proxy, risks desynchronizing user-facing site UI from the stateful tools on the server which will likely the confuse the user, or AIs that are trained to act like users to observe and react to site UI for feedback. I can get together a PR to make this more crisp in the README.
- Revise examples that wrap service calls in page JavaScript. Show the service operation through remote MCP and reserve WebMCP for the genuinely client-local part of the same workflow.
I think most examples do this well already, can you clarify which ones you'd like to see updated? The first example in https://github.com/webmachinelearning/webmcp#e-commerce--tailored-shopping could be better since it's just a pass-through for
fetch()which cuts against my argument to not make your WebMCP tools just server-proxies. But the others I think handle this well.- Explain how a browser session can use an existing remote MCP capability without each website re-registering it as a second client-side tool interface.
I could take or leave this. I guess the ask here is to show that built-in agents like Gemini-in-Chrome, Copilot-in-Edge, and ChatGPT's in app browser's AI agent can already form MCP connections to sites themselves, thus giving another reason for web developer to not re-expose their MCP tools as WebMCP tools?
Thanks for the detailed response. The distinction I’m drawing is whether a capability needs the running browser, not whether WebMCP itself runs in one. An unsaved edit or current selection needs that browser. A product query or server-owned cart operation does not.
The institutional incentive matters here. The README presents reduced developer burden and reuse of client JavaScript as benefits. Registering tools in the existing website can fit its current codebase, team and deployment path. Exposing an independently reachable service capability requires organisations to make a different ownership and authorization decision. The specification needs to counter the pressure to take the smaller change for every operation.
On proxying, I agree with your answer: do not wrap remote MCP tools as WebMCP tools. For a service operation, an MCP-capable agent should call the service directly. The website remains a client for the user. If another tab, mobile app or agent changes server state, the open page needs to reconcile with it. That is a multi-client synchronization problem, not a reason to require every agent call to pass through the page. When no page is open, there is no visible UI to synchronize. An MCP tool also returns its result directly; the agent does not need to watch the website to infer what happened. Remote MCP authorization supports OAuth with PKCE, so user login does not require running the website’s JavaScript.
The e-commerce example shows the boundary clearly.
get-dressesfetches product data and returns JSON. That is a service capability to expose through remote MCP.show-dressesandfilter-productschange the current page, so WebMCP fits them. Makingget-dressesupdate the UI as an extra side effect would conceal the boundary rather than correct it.My final bullet asked for guidance on using those two kinds of tools alongside each other: remote MCP for service capabilities, WebMCP for the live page. It did not ask websites to duplicate remote tools in JavaScript, and it did not assert that each named browser agent already supports remote MCP.
The website should stay available for human interaction and for agent work that genuinely depends on its live state. It should not become a mandatory runtime for browser-independent service operations. That is the architectural default the guidance and examples need to establish.
The architectural boundary needs to be explicit
The README says replacing backend integrations is a non-goal. Its goals also say to prevent web content disintermediation and that any task a user can accomplish through a page's UI can be turned into a tool. The
get-dressesexample exposes a product query through page JavaScript. Those examples and goals teach a broader pattern than the non-goal rules out.Given a choice between exposing a BFF or service capability through remote HTTP MCP and registering a wrapper in the existing website, organisations will take the smaller, browser-centric change. That makes the loaded website the agent interface for ordinary operations such as
getProducts,addToCart,getOrders, andmoveWorkItem. The agent then needs a browser, the site's JavaScript bundle, and its client lifecycle to reach a capability that exists independently of them.This is the wrong ownership boundary. A website is a consumer of service capabilities; it should not become the required runtime for an agent to use them. WebMCP has a distinct role when an operation depends on the running client: unsaved edits, current selections, viewport state, local rendering state, or direct collaboration in the user's active UI. Ordinary domain and service operations belong at the service boundary and should be exposed to agents through remote MCP.
The stated non-goal does not counteract the implementation path the API and examples encourage. This is an adoption problem, not a question of the designers' intent.
Requested change
Make the boundary explicit in the specification guidance and examples:
This is distinct from the interoperability mechanics in #83 and #84, the broader positioning questions in #97, and the parallel-description concern in #91. The issue is the architectural default that WebMCP's guidance will establish. If ordinary service operations are presented as WebMCP tools, organisations will build browser-dependent agent interfaces instead of exposing their services directly.