fix: include transport path in Protected Resource Metadata resource URL

[Br1an67]

Summary

Fixes #1264

The resource field in /.well-known/oauth-protected-resource was set to the base resource_server_url (e.g., http://localhost:8000/) instead of the actual protected endpoint URL (e.g., http://localhost:8000/mcp). Per RFC 9728, the resource identifier must match the URL that clients use to access the protected resource.

This caused VS Code Copilot (and other compliant clients) to reject the server with:

Protected Resource Metadata resource "http://localhost:8000/" does not match MCP server resolved resource "http://localhost:8000/mcp"

Changes

• src/mcp/server/lowlevel/server.py: Append streamable_http_path to resource_server_url when constructing the resource URL for both the protected resource metadata endpoint and the WWW-Authenticate header.
• src/mcp/server/mcpserver/server.py: Same fix for the SSE transport path.

Test

uv run pytest tests/server/auth/test_protected_resource.py -x  # 14 passed
uv run pytest tests/server/mcpserver/auth/ -x  # 42 passed
uv run ruff check src/mcp/server/lowlevel/server.py src/mcp/server/mcpserver/server.py  # All passed

[maxisbey]

Thanks for the PR and for digging into this — the underlying VS Code error is real and the issue has bitten multiple people. However, the approach here introduces a regression for servers that are already configured correctly, so I'm going to close this in favor of a docs-focused fix.

Why appending streamable_http_path doesn't work

Double path for correctly-configured servers. PR #1407 (Oct 2025) established that resource_server_url should be the full endpoint URL, and simple-auth was updated accordingly:

python-sdk/examples/servers/simple-auth/mcp_simple_auth/server.py

Line 34 in 528abfa

server_url: AnyHttpUrl = AnyHttpUrl("http://localhost:8001/mcp")

With that config, this PR produces:

"http://localhost:8001/mcp".rstrip("/") + "/mcp"  →  "http://localhost:8001/mcp/mcp"

streamable_http_path is the wrong coordinate system. It's the route inside the Starlette app, not the public URL. The SDK's own multi-server example mounts with streamable_http_path="/" under Mount("/api", ...):

python-sdk/examples/snippets/servers/streamable_http_multiple_servers.py

Lines 44 to 45 in 528abfa

	Mount("/api", app=api_mcp.streamable_http_app(json_response=True, streamable_http_path="/")),
	Mount("/chat", app=chat_mcp.streamable_http_app(json_response=True, streamable_http_path="/")),

Here the endpoint is /api but streamable_http_path is / — concatenation gives the wrong answer. Same for reverse proxies. Only the user knows the public URL.

Diverges from the TypeScript SDK, which uses resourceServerUrl.href verbatim: https://github.com/modelcontextprotocol/typescript-sdk/blob/978b6ccaeaa6ca561e6f1f07874d09b02d754f98/src/server/auth/router.ts#L206

The actual gap (bigger than I first thought)

#1407 established the contract but didn't update everything. Still broken on main:

• examples/snippets/servers/oauth_server.py:27 — http://localhost:3001 (missing /mcp)
• README.md:1036 — same snippet embedded
• AuthSettings.resource_server_url docstring — doesn't say "include the transport path"
• simple-auth/server.py:131 hardcodes /mcp but line 105 offers --transport=sse — run with SSE and you get the same RFC 9728 mismatch

Worth noting: the python-sdk client uses hierarchical prefix matching (auth_utils.py:65) rather than RFC 9728 §3.3 strict equality, so python↔python testing accepts the misconfiguration that VS Code rejects. That's part of why this keeps surfacing.

There's also a genuine API awkwardness here — AuthSettings is construction-time but streamable_http_path is transport-time, so the two have to be kept in sync manually. A startup warning when they disagree would catch this at boot instead of at the VS Code 401. Worth tracking separately.

If you'd like to take the docs/example fixes as a follow-up PR, that would close #1264 properly. Happy to help scope it.

_{AI Disclaimer}