Prevent WebMCP from becoming a browser-dependent substitute for remote MCP
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- html
- Domain
- documentation
Research direction
Start by reading the specification guidance, README goals and get-dresses example referenced in the issue, then compare the distinction with #83, #84, #97 and #91. Revise the guidance and examples to distinguish browser dependent capabilities from service operations, show remote MCP for service operations, and explain how a browser session can use those capabilities. Done when the requested boundary is clear throughout the guidance and examples.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Bikeshed
- Stars
- 4.7k
- Forks
- 328
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 16
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from webmachinelearning/webmcp
-
Difficulty 1/5 1-3 hours Newbie friendliness 72/100
webmachinelearning/webmcp#360 ·
Maintainers usually reply within 1 day
-
Say how an agent should weigh annotations that the page wrote about itselfPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
webmachinelearning/webmcp#353 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
webmachinelearning/webmcp#343 · 1 reaction ·
Maintainers usually reply within 1 day
-
Agenda+ i18n-tracker
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
webmachinelearning/webmcp#273 · 3 comments ·
Maintainers usually reply within 1 day
-
a11y-tracker Agenda+
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
webmachinelearning/webmcp#272 · 4 comments · 2 reactions ·
Maintainers usually reply within 1 day
All issues in webmachinelearning/webmcp
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
bluerobotics/Cockpit-docs#48 ·
-
ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
xavxyz/bei-shan-lin-shui#57 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
mozilla/standards-positions#1472 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
w3c/json-ld-api#735 ·