Spec problem with authorization and streaming?

[djMax]

Is your feature request related to a problem? Please describe.
If I have a single MCP server that intends to expose both authenticated and unauthenticated tools, and uses multi-message transports like streamable HTTP, how is a tool supposed to indicate that auth is required for a tool call?

Describe the solution you'd like
A declarative method to say "this tool needs auth" or a way to throw an error that tells the server to tell the client auth is required.

Describe alternatives you've considered
I can't see one, but I'm no protocol expert. I tried sending 401 to the response directly, but headers have already been sent.

[mgyarmathy]

The MCP spec currently doesn't offer a solution to servers that have a mixed bag of authenticated and anonymous tools.

There are a few SEPs related to your question:

• SEP-835: Update authorization spec with default scopes definition (approved)
• SEP-1488: securitySchemes in Tool Metadata for Mixed-Auth Servers
• SEP-1489: Tool Error Responses for Triggering OAuth Flows

I recommend you follow up in one of those threads, or ask your question in the #auth-ig channel of the MCP Contributors Discord.

[KKonstantinov]

You could achieve this even today, but you will need some custom logic in your MCP server setup.

Currently you register all the tools on each request. If you've an authorization header, and depending your business logic, you can choose which tools to leave enabled or disabled. (or even choose to not register them, up to you).

[djMax]

That doesn't really solve it because there's no way for me to say "there is a tool, but you need auth to use it, so go auth and then come back and use it."

[KKonstantinov]

Understood your scenario, in that case, you're correct - there's currently no way to have the tool listed and then indicate you need to auth to use it.

[pcarleton]

@djMax could you give this a read and let me know if it covers your issue?
#1151

[djMax]

That would definitely do it, assuming upstream respected it. I would suggest though that there still might be an "in-execution" version of it that would be useful. i.e. a particular exception or return format that allowed the tool to say "I don't know at registration time that I need something, but I've figured it out now and I do"

[pcarleton]

That would definitely do it, assuming upstream respected it.

what's the upstream in this case? not sure I followed that comment.

I would suggest though that there still might be an "in-execution" version of it that would be useful.

Is this different than (2) in that issue, describing throwing a ScopeChallengeError error mid-tool call?

[djMax]

No - 2 covers it, I just missed it on the first read. By upstream I just meant that assuming the tool callers respect the spec (which seems like it does enable this, but only recently), then this is a complete solution. But if they required all auth statements to be made up front, then I don't know how this ends up feeling devex wise.

[djMax]

The big 'decision' here IMHO is that you're using scopes to mean everything. I think that's fine, because in the end scopes are just strings and I could demand the "user:123456" scope if I wanted to.