fix: include transport path in Protected Resource Metadata resource URL - #2189
fix: include transport path in Protected Resource Metadata resource URL#2189Br1an67 wants to merge 1 commit into
Conversation
Sorry, something went wrong.
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. Append the transport path (streamable_http_path or sse_path) to the resource_server_url in both lowlevel/server.py and mcpserver/server.py.
|
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 workDouble 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: 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", ...): 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:
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. |
Sorry, something went wrong.
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:
Changes
Test