Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#322 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
文档
描述清晰度
描述清楚
活跃度
活跃
技术栈
html
领域
documentation

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Bikeshed
星标
4.7k
派生
328
平均合并
2 天 15 小时
30 天内合并 PR
16

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

webmachinelearning/webmcp 的其他 Issue

查看 webmachinelearning/webmcp 的全部 Issue

相似的 Issue

更多 Documentation Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。