Coincidentally there may already be a case for a preflight request for other purposes. As @findleyr mentioned on Discord, we might not be able to support forwarding of 403 errors during tool calls due to SEP-1699 and so we might wish to enable a preflight checks to support scope 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 example codeAction/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 with tools/list responses

Added LSP context with comparison table

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

Added Future Extensibility section

• Discussed potential uses for scope requirements (addressing my 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.

@SamMorrowDrums this SEP does not have an assigned sponsor. Are you looking to continue working on it and find sponsorship?

Very much so @localden, it underpins several things I think are important when needed, I have got a few folks interested (including some major companies in the space) but I'm not sure how best to identify a sponsor.

If you have any advice I'd love to hear it. I'll bring it up on discord, perhaps I just need to work out which group would care most on discord or propose an IG, if there isn't one.

I'm going to have some opportunity in the Tool Scopes WG to see if it's a good fit there shortly, given that there isn't a 1:1 mapping with scopes and tools and it's not clear until runtime what the concrete requirement would be, it could be adopted for this.

I believe it would make the trust and privacy SEP proposal better too, reduce over prompting and give MCP clients a better UX.

I discussed its possible applicability to FGP with @nbarbettini last week also.

Need a little more time, and might need to tighten up the elevator pitch to encourage more interest.

@localden @nicknotfun will be sponsoring.

State Transition: proposal → draft

This SEP has been transitioned from proposal to draft.

@nickcoai has been assigned as the sponsor for this SEP.

This is an automated message from the SEP lifecycle bot.

This is a nice proposal and I'm generally a big fan. Some notes:

• The resolved tool returns inputSchema again. How should a client handle if this is different from the unresolved schema -- it could potentially invalidate the input just passed to the tool? The SEP says "other fields may match the original" but this is not a MUST. And if this is the case, should we just omit the fields that are immutable in the resolve result?
• I wonder if this should be a server capability vs a annotation on the tool schema which is resolve-able. This feels like something that a server wouldn't necessarily care to implement for every single tool.
• "Clients MAY skip resolution for tools where static metadata is acceptable" -- I'm not sure what this means.

"Clients MAY skip resolution for tools where static metadata is acceptable" -- I'm not sure what this means

What I intended here is that if a client wasn't going to prompt a user anyway (because for example they enabled skipping confirmations for a given tool, all write tools or they're running yolo mode), the result of the resolution would be immaterial to the client and therefore could be reasonably skipped.

The static annotations are meant to represent the worst case and so clients should be free to determine if there would be any value in the call.

The caveat to this is if we were to one day extend tools/resolve to support additional actionable data or behaviours such as issuing a scope challenge, it would then be better if clients always called tools/resolve when offered.

Do you have a suggestion for rephrasing @connor4312 or do you think we should just remove this part?