Repository navigation
Proposal: Per-tool scopes for WebMCP #102
Description
Problem
Tools need declarative permission requirements. Currently, auth and capabilities are entangled — tools either get full access or none.
Proposal
A scopes field on tool definitions:
navigator.modelContext.provideContext({
tools: [{
name: "update_profile",
scopes: ["profile:write"],
execute: async (args, context) => {
return await updateProfile(args, context.auth);
}
}, {
name: "read_profile",
scopes: ["profile:read"],
execute: async (args, context) => {
return await getProfile(context.auth);
}
}]
});Semantics
- UA enforces scopes before tool execution
- Scopes are declarative — UA can prompt users per-scope
- Model sees tool names and descriptions, but NOT scopes
- Scope format:
resource:action(aligned with OAuth conventions)
Open Questions
- Should scopes map to existing web permissions (Permissions API)?
- Should the UA aggregate scope prompts or prompt per-tool?
- How do scopes interact with HTTP header-based discovery (see Proposal: Session and authentication context for tools #87)?
Related: #87
Activity
DavidMulder0 commentedon Feb 26, 2026
What would be the point when the page can simply show a prompt to the user to (dis)allow any tool to be used? Why would the UA have to be involved in this? Reminder: "Headless browsing scenarios" and "Autonomous agent workflows" are explicit non-goals of this spec.
hemanth commentedon Feb 26, 2026
This isn't about headless or autonomous scenarios. It's about giving the UA enough information to enforce permissions consistently, same way the Permissions API does for geolocation or camera access.
If each page rolls its own prompt, you get inconsistent UX across sites, no way for the UA to remember user decisions across sessions, and no standardized way for a user to audit or revoke what tools have access to. The page can prompt, but the page also has an incentive to skip the prompt or bury it.
The UA as enforcement layer is the same trust model the web already uses, sites declare what they need, the browser mediates consent. Scopes are just the declaration format that makes that possible for tools.
If the consensus is that tool permissions should stay page-managed, how do we handle cases where a tool silently escalates from read to write without the user knowing?
DavidMulder0 commentedon Feb 27, 2026
Tool usage is about the user executing code on the website they are on. It's like having a button on a website, and a user clicking a button on a website. The only difference is fundamentally that the process is less deterministic (the user 'says' which buttons they want clicked, and in 99% of cases those buttons will get clicked). Websites could already do all this by themselves if they bring their own LLM (or use the Prompt API, but that model is kind of too small for this stuff), they don't need the UA for this. All this does is make it easy for developers to add a chat based interaction pattern to their applications.
Geolocation or camera access are about the UA giving information to a third party (the website).
The web is build around the idea of each website defining their own UX, so the only consistent UX would be the UX provided by the website. Just look at geolocation and how much trouble they have been going through to try to move away from UA provided UI.
Why would a UA even 'want' to track this?
A tool doing stuff is the entire point of a tool. It's just an arbitrary 'button' (more like form) that an LLM can press. Whether a website wants to prefill a JIRA issue form, fill and submit a form, show the user the weather in Ontario, play some music, or hire a clown to go dance on the street.
A 'tool' is just a new UX 'element' that can be 'exposed' to the user.
All that said, I am a big proponent of semi-enforced standardized tool 'hints'. (from MCP spec https://modelcontextprotocol.io/specification/2025-06-18/schema#toolannotations, e.g. discussed here in #53 ). These allow a UA to expose to the user 3 'levels' the user can pick from (allow only read only tools, allow read only tools without user confirmation, and other tools with user confirmation, allow all tools). Crucially though "NOTE: all properties in ToolAnnotations are hints. They are not guaranteed to provide a faithful description of tool behavior"
domfarolino commentedon Mar 2, 2026
The semantics are not clear to me. What would the UA enforce here? What should the allowed/standardized list of "scopes" be? For the reasons that @DavidMulder0 described above, I get the sense that the scoping idea as outlined here is all that compatible with the direction of WebMCP, so I think it's best to close this, but please post a clarification if you think I'm wrong @hemanth.
hemanth commentedon Mar 3, 2026
To add more context: the motivation here is that as WebMCP tools interact with user data (files, profiles, browsing context), we need a way for the UA to enforce least-privilege before execution. Without per-tool scopes, tools are either fully trusted or fully blocked.
A few thoughts on the open questions:
Mapping to Permissions API — I think scopes should be a superset. Web Permissions cover device-level access (camera, geolocation), but WebMCP scopes would cover data-level access (profile:read, files:write). The UA could bridge both where they overlap.
Aggregated vs per-tool prompts — Aggregating makes sense for initial consent (like OAuth consent screens), but the UA should retain the ability to prompt individually for sensitive scopes.
Interaction with Proposal: Session and authentication context for tools #87 — Session-scoped auth tokens could carry granted scopes, so the server knows what the client is allowed to do without re-checking on every call.
Would love feedback on how this fits with the broader tool execution model.
hemanth commentedon Mar 3, 2026
On second thought, this might be premature. The UA already mediates tool execution and can prompt per-tool without needing a formal scopes taxonomy. The browser's native permission model may be sufficient for now. Parking this until there's a clearer need.
Bundle application, workers, server, and Electron using Rollup