Host-controlled WebMCP access between iframes
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- html
- 領域
- api
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Bikeshed
- スター
- 4.7k
- フォーク
- 328
- 平均マージ
- 2日 15時間
- マージ済み PR（30日）
- 16
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
webmachinelearning/webmcp のほかの issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 72/100
webmachinelearning/webmcp#360 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Say how an agent should weigh annotations that the page wrote about itself対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
webmachinelearning/webmcp#353 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
webmachinelearning/webmcp#343 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Agenda+ i18n-tracker
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
webmachinelearning/webmcp#273 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
a11y-tracker Agenda+
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
webmachinelearning/webmcp#272 · コメント 4 件 · リアクション 2 件 ·
メンテナーはふだん 1 日以内に返信
webmachinelearning/webmcp の issue をすべて見る
似ている issue
-
[Bug]: IndexHandler.post crashes with HTTP 500 on malformed payloads, missing credentials, or when login is disabled対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 6 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
zerocracy/judges-action#2849 ·
メンテナーはふだん 1 日以内に返信
-
fix: @_helpers.positional raises TypeError when decorating functions without default arguments対応中かも @codeXsidd が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
googleapis/google-api-python-client#2845 ·
メンテナーはふだん 1 日以内に返信
-
status: needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
JabRef/jabref#17546 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信