Coincidentally there may already be a case for a preflight request for other purposes. As@findleyrmentioned on Discord, we might not be able to support forwarding of 403 errors during tool calls due toSEP-1699 and so we might wish to enable a preflight checks to supportscope challenges also.

cc@dend

By comparison, LSP has a notion of 'resolve', which is when the client asks the server to 'finish filling out' a particular stub. For examplecodeAction/resolve, though this exists for many constructs.

That's slightly different, because the client isn't passing in any specific arguments in the resolve request: it's simply exchanging the stub for a fully filled-out version, but I think there's something to be learned from the design: we probably want to avoid a future where there are a bunch of separate preflight checks for a single tool call--it would be better to consolidate them into a single exchange. I'm not sure what that means, concretely: do we return the entire tool from the preflight check, rather than just its annotations?

Revised Direction

Thanks@findleyr for the excellent feedback on adopting an LSP-inspired resolve pattern. I've substantially revised this SEP based on your suggestions and additional considerations around extensibility.

Key Changes

Renamed concept:tools/annotations →tools/resolve

• Field:dynamicAnnotations →resolve
• Capability:dynamicAnnotations →resolve
• Method:tools/annotations →tools/resolve

Returns full Tool object instead of just annotations

• Enables future extensions (scopes, costs, rate limits) without new preflight methods
• Follows the principle of "consolidate into a single exchange"
• Maintains structural consistency withtools/list responses

Added LSP context with comparison table

• Clarified that we'readapting LSP's useful patterns for MCP
• Key difference: MCP tools are fully functional fromtools/list, resolution refines metadata based on intended arguments

Added Future Extensibility section

• Discussed potential uses for scope requirements (addressingmy comment about scope challenges)
• Noted these are out of scope but the mechanism supports them

Cleaned up examples

• Consolidated duplicate file examples
• Removed redundant sections

Open for Discussion

I'd appreciate feedback on:

1. The naming (resolve vs alternatives)
2. Whether the LSP comparison is helpful or distracting
3. The scope of "future extensibility" - should we be more or less specific?

The goal is a clean, extensible foundation that avoids the "proliferation of preflight methods" concern@findleyr raised.

As an example trying to do Scope Challenge for GitHub MCP, I would ideally allow public repo access without a repo scope challenge, however then I won't be able to send a challenge for accessing private repos, so the granularity of 1 scope for one tool is definitely not sufficient for our use case. In order to allow least privilege generally, I am forced to provide a scope challenge for all available data, which is a problem when a legitimate user wants to access only public repo data and not give the token full repo scope.

This is currently not solvable.