Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#322 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
html
Ambito
documentation

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Bikeshed
Stelle
4.7k
Fork
328
Merge medio
1g 21h
PR unite (30g)
15

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webmcp

Tutte le issue di webmachinelearning/webmcp

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.