Prevent WebMCP from becoming a browser-dependent substitute for remote MCP

[AdamCoulterOz]

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-dresses example 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, and moveWorkItem. 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:

• State that WebMCP is for capabilities whose meaning or state depends on the running browser client or shared UI session.
• Direct developers to expose browser-independent domain and service capabilities through remote MCP, even when the web UI also calls them.
• 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.
• 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.

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.

[domfarolino]

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?