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

WebMCP loses important context when tools appear or disappear

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript
領域
api

調査の方向性

Read the related discussions #87, #96, #102, and #167 to understand how this proposal overlaps with existing work. The issue asks for a standard way to expose why a capability is unavailable while leaving authorization with the site, but does not identify files, tests, or a specific API. Done would mean a concrete design for preserving that context in the agent-visible tool surface.

索引モデルが issue の本文から書いたものです。

説明

Problem

WebMCP currently gives agents a very simple view of capability state: a tool is either available or it is not.

That works for simple cases, but real applications have much richer state behind those tools.

A tool may become unavailable because:

  • the user does not have permission
  • their subscription does not include the feature
  • they switched organizations or workspaces
  • the current workflow is not ready for that action
  • a resource is still processing
  • the feature is temporarily unavailable

The site usually knows exactly why.

But when the site responds by simply registering or unregistering the tool, that meaning is lost. The agent only sees that the tool disappeared.

I think this creates a form of semantic context blindness.

Example

Imagine a reporting application.

A user asks an agent:

"Export this report."

Earlier, the agent could see:

export_report

The user then switches to another workspace where exports are not included in their plan.

The application unregisters export_report.

Now the agent only knows:

export_report no longer exists.

It cannot tell whether:

  • the user lacks permission
  • the workspace plan does not support exports
  • the report is not ready yet
  • exports are temporarily unavailable
  • or something else changed

Those situations should lead to very different agent behavior.

If the agent knew:

Export is unavailable because this workspace does not include report exports.

it could explain that to the user and continue helping with the parts of the workflow that are still available.

Developer-side problem

Leaving this entirely to application code also makes developers responsible for keeping the WebMCP tool registry synchronized with constantly changing application state. It also poses security concerns, due to constant changes that would need to happen, and coding changes that need to be maintained by a developer.

For example:
.js

if (canExport) {
registerTool(exportReport)
} else {
unregisterTool("export_report")
}

That seems simple until an application has dozens of tools and permissions can change because of login/logout, organization switching, subscription changes, role changes, feature flags, or async workflow state.

It becomes easy to:

  • forget to remove a tool when access changes
  • repeatedly register/unregister tools unnecessarily
  • create races where an agent plans around a tool just as it disappears
  • hide an entire tool even though only one operation inside it is restricted

Async/service-style tools make this even more noticeable.

For example, one manage_report tool might allow a user to view and edit a report, while exporting requires an additional permission. Removing the entire tool because export is unavailable would also hide the operations the user is still allowed to perform.

What I think is missing

I am not suggesting that WebMCP should become an OAuth or authorization system, or that the browser should understand every site’s permission model.

The site should remain responsible for authentication and authorization.

But it may be useful for WebMCP to have a standard way for a site to preserve some of the meaning behind capability changes instead of reducing everything to:

tool exists / tool does not exist

For example, a site could communicate that a capability is currently unavailable and optionally provide a reason such as:

  • permission required
  • entitlement required
  • authentication required
  • invalid current state
  • temporarily unavailable

The exact API is less important to me than preserving that semantic context.

Related discussions

This seems related to:

  • #87 — authentication/session context
  • #96 — scopes and delegation context
  • #102 — per-tool scopes
  • #167 — dynamic tool updates and registration churn

I think this is slightly different from those discussions because the core problem is not specifically scopes.

The broader issue is that rich application capability state is currently being projected into a binary tool-presence signal, and useful context is lost between the site and the agent.

MCP naturally sits at the backend authorization boundary; WebMCP does not. WebMCP therefore needs a cleaner way to project backend capability state into the agent-visible tool surface, without reducing everything to syncing tools with register/unregister.

主要言語
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

Backend & API Design の issue をもっと見る

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

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