Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#322 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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時間
マージ済み PR（30日）
16

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

webmachinelearning/webmcp のほかの issue

webmachinelearning/webmcp の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。