Is one-auth-configuration-per-server a deliberate constraint?

Comece por AuthSettings e pela publicação de authorization_servers em server/mcpserver/server.py:1207; em seguida, acompanhe o único token_verifier em MCPServer. Revise client/auth/oauth2.py nas linhas referenciadas para entender o comportamento atual da primeira entrada e seu TODO; o trabalho estará concluído quando houver uma decisão documentada ou um design definido para oferecer suporte às duas configurações de autenticação.

Initial Checks

• I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Release line

2.x (current stable)

Description

Hi! Is one-auth-configuration-per-server in the Python SDK a deliberate constraint, or just something nobody has needed yet?

Use case

I have an MCP server for text search that enforces per-user article permissions from our main system. One deployment needs to serve two kinds of caller:

1. Service-to-service (internal). Our frontend authenticates the user, the backend receives only the user's token and passes it to the MCP server — this avoids redirect-based logins between internal services. The MCP server then exchanges that token with our SSO for a token valid for a third system, so it needs a confidential client with a client_secret.
2. Interactive (external). I'd like the same server to also expose a "public" entry point, so a user can add it to Claude Desktop / Codex and go through normal OAuth with a public client (PKCE, no secret).

Today AuthSettings allows exactly one configuration

• issuer_url is a single AnyHttpUrl, and the server always publishes it as a one-element list — server/mcpserver/server.py:1207:

authorization_servers=[self.settings.auth.issuer_url]

• the client only ever reads the first entry — client/auth/oauth2.py:349 and :630, with a # todo: try all authorization_servers to find the OASM
• and there is one token_verifier per MCPServer.

The workaround, and why it doesn't hold up

The obvious approach is two MCPServer instances sharing the tool functions (see Example Code below). Stacking the decorators is fine (tool() returns the function unchanged). Mounting is where it falls apart. Both apps can't be mounted at / — the first one matches everything and the second is never reached. And once the second is mounted under a prefix, its RFC 9728 metadata route (generated from resource_server_url) is served from under that prefix:

200  /public/.well-known/oauth-protected-resource/public/mcp   <- where it actually is
404  /.well-known/oauth-protected-resource/public/mcp          <- where the client looks

So the second server is undiscoverable unless I re-register the well-known route at the app root by hand. That's the part that feels like it should be SDK support rather than a workaround.

Question

Is one auth config per server intentional — and if so, what's the recommended way to cover both cases? Or would you be open to multiple auth configurations / multiple token verifiers per server? Happy to put up a PR if there's interest.

Example Code

mcp = MCPServer(token_verifier=JwtTokenVerifier(),
                auth=AuthSettings(resource_server_url="https://host/mcp", ...))
mcp_public = MCPServer(token_verifier=PublicJwtTokenVerifier(),
                       auth=AuthSettings(resource_server_url="https://host/public/mcp", ...))

@mcp.tool()
@mcp_public.tool()
async def search(...): ...

Python & MCP Python SDK

Python 3.14.2
MCP Python SDK 2.0.0