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

WebMCP loses important context when tools appear or disappear

Aperta
  • Qualcosa non va?
#262 7 commenti 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à
Tranquilla
Stack tecnologico
javascript
Ambito
api

Direzione di ricerca

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.

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

Descrizione

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.

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

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.