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

Host-controlled WebMCP access between iframes

Aperta
  • Qualcosa non va?
#317 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
html
Ambito
api

Direzione di ricerca

Start by reading the WebMCP permission model, especially how exposedTo and fromOrigins currently govern cross-origin tools; the issue does not name specific files or tests. Decide whether hosts should be able to delegate separate provider and consumer capabilities, and define how providers opt into host-authorised exposure. Done means the permission and provider opt-in model supports the described iframe topology without requiring apps to know the agent origin.

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

Descrizione

enhancement

Consider a host application that composes several cross-origin applications in iframes, with one iframe containing an agent:

Host
├── Agent iframe
├── App A iframe
├── App B iframe
└── App C iframe

Apps A–C may expose WebMCP tools. The host wants the agent to use those tools, but does not necessarily want the apps to discover or invoke tools exposed by other frames.

The host therefore wants to define a topology like:

Frame Expose tools Use tools
Agent no yes
App A yes no
App B yes no
App C yes no

The current model seems awkward for this use case because cross-origin access relies on providers and consumers knowing each other's origins through exposedTo and fromOrigins.

In a composed application, the embedded apps may not know or care which agent implementation the host uses. The host is the component that knows the intended relationship between the frames.

Would it make sense to separate the current tools permission into two independently delegatable capabilities, conceptually:

<iframe src="https://app.example"
        allow="tools-provide">

<iframe src="https://agent.example"
        allow="tools-consume">

This would let the embedding host decide which frames may expose WebMCP capabilities and which frames may consume them.

There would probably also need to be a way for a provider to opt into host-authorised exposure, rather than having to enumerate every possible consuming agent origin.

This seems particularly useful for host applications that compose independent first- and third-party web applications alongside an embedded agent.

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 Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.