Skip to content

Fix resource metadata discovery URL construction to comply with MCP spec for subpath deployments#1110

Open
AnkeshThakur wants to merge 1 commit intomodelcontextprotocol:mainfrom
AnkeshThakur:main
Open

Fix resource metadata discovery URL construction to comply with MCP spec for subpath deployments#1110
AnkeshThakur wants to merge 1 commit intomodelcontextprotocol:mainfrom
AnkeshThakur:main

Conversation

@AnkeshThakur
Copy link

@AnkeshThakur AnkeshThakur commented Feb 24, 2026

Summary

  • Adds getResourceMetadataDiscoveryUrl() utility in oauthUtils.ts that correctly constructs the protected resource metadata discovery URL per RFC 9728 §3 and the MCP spec
  • Replaces all three inline new URL("/.well-known/oauth-protected-resource", serverUrl) usages in OAuthFlowProgress.tsx with the new utility via a memoized resourceMetadataDiscoveryUrl variable
  • Adds 6 unit tests covering: single-segment path, subpath, deep path, trailing slash, no path, and URL object input

Problem

The previous code used:

new URL("/.well-known/oauth-protected-resource", serverUrl)

This always resolves to the host root, ignoring the resource endpoint path entirely. For subpath-deployed MCP servers (e.g. https://host/public/mcp), the metadata URL was incorrectly constructed as https://host/.well-known/oauth-protected-resource instead of https://host/.well-known/oauth-protected-resource/public/mcp.

Fixes #1008.

Spec Compliance

Per RFC 9728 §3 and the MCP spec §authorization#protected-resource-metadata-discovery-requirements, the well-known URL is formed by inserting /.well-known/oauth-protected-resource at the origin root and appending the full resource path after it:

Resource URL Correct metadata URL
https://host/public/mcp https://host/.well-known/oauth-protected-resource/public/mcp
https://host/resource https://host/.well-known/oauth-protected-resource/resource
https://host (no path) https://host/.well-known/oauth-protected-resource

This matches the MCP SDK's own implementation: new URL(`/.well-known/oauth-protected-resource${rsPath}`, u).

Test plan

  • All existing unit tests pass (npm test in client/)
  • New tests cover: single-segment path, subpath, deep path, trailing slash, no-path URL, URL object input
  • Manual: connect to a subpath-deployed MCP server and verify the resource metadata URL resolves correctly

🤖 Generated with Claude Code

…pec for subpath deployments

Per RFC 9728 §3 and the MCP spec (https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#protected-resource-metadata-discovery-requirements),
the .well-known/oauth-protected-resource URL is formed by inserting the
well-known prefix at the origin root and appending the resource path after it:

  https://example.com/public/mcphttps://example.com/.well-known/oauth-protected-resource/public/mcp

The previous code used `new URL("/.well-known/oauth-protected-resource", serverUrl)`
which always resolves to the host root, ignoring the resource path entirely.
This broke metadata discovery for any subpath-deployed MCP server (issue modelcontextprotocol#1008).

Changes:
- Add `getResourceMetadataDiscoveryUrl()` in oauthUtils.ts that prepends
  /.well-known/oauth-protected-resource at the origin and appends the resource
  pathname (trailing slash stripped), matching the MCP SDK implementation
- Replace all three inline well-known URL constructions in OAuthFlowProgress.tsx
  with the new utility via a memoized `resourceMetadataDiscoveryUrl` variable
- Add 6 unit tests covering: single-segment path, subpath, deep path,
  trailing slash, no path, and URL object input

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MCP inspector adding incorrect url Oauth discovery URL

1 participant