Inspector Version
Describe the bug
OAuth metadata discovery fails for MCP servers mounted at a sub-path when protected resource metadata is unavailable. The fallback authorization server URL is collapsed to the bare origin, stripping the mount path entirely — so the RFC 8414 path-aware discovery endpoint the server actually exposes is never attempted.
To Reproduce
- Run a FastMCP server mounted at a sub-path, e.g.
https://host/api/mcp/github/mcp (no explicit /.well-known/oauth-protected-resource route, or one blocked by CORS).
- Open Inspector and enter
https://host/api/mcp/github/mcp as the server URL.
- Initiate the OAuth flow and observe the
metadata_discovery step.
- Flow fails with
"Failed to discover OAuth metadata", the correct path-aware URL https://host/.well-known/oauth-authorization-server/api/mcp/github was never tried; only https://host/.well-known/oauth-authorization-server was attempted.
Expected behavior
When protected resource metadata is unavailable, Inspector should fall back to the RFC 8414 path-aware discovery form (/.well-known/oauth-authorization-server{/mount-path}) derived from the MCP server URL, rather than discarding the mount path and querying the bare origin.
Environment:
- OS: Windows 11
- Browser: Chrome 146.0.7680.164 (Official Build) (64-bit)
Additional context
getAuthorizationServerMetadataDiscoveryUrl already implements the RFC 8414 path-aware URL form correctly. The issue is that the fallback authServerUrl is initialized as new URL("/", context.serverUrl), which strips the path before that function is ever called. The path-aware branch is unreachable in the failure scenario. The failure also surfaces as a generic terminal error with no indication that the root cause was an incorrect discovery URL rather than an unreachable authorization server.
Inspector Version
Describe the bug
OAuth metadata discovery fails for MCP servers mounted at a sub-path when protected resource metadata is unavailable. The fallback authorization server URL is collapsed to the bare origin, stripping the mount path entirely — so the RFC 8414 path-aware discovery endpoint the server actually exposes is never attempted.
To Reproduce
https://host/api/mcp/github/mcp(no explicit/.well-known/oauth-protected-resourceroute, or one blocked by CORS).https://host/api/mcp/github/mcpas the server URL.metadata_discoverystep."Failed to discover OAuth metadata", the correct path-aware URLhttps://host/.well-known/oauth-authorization-server/api/mcp/githubwas never tried; onlyhttps://host/.well-known/oauth-authorization-serverwas attempted.Expected behavior
When protected resource metadata is unavailable, Inspector should fall back to the RFC 8414 path-aware discovery form (
/.well-known/oauth-authorization-server{/mount-path}) derived from the MCP server URL, rather than discarding the mount path and querying the bare origin.Environment:
Additional context
getAuthorizationServerMetadataDiscoveryUrlalready implements the RFC 8414 path-aware URL form correctly. The issue is that the fallbackauthServerUrlis initialized asnew URL("/", context.serverUrl), which strips the path before that function is ever called. The path-aware branch is unreachable in the failure scenario. The failure also surfaces as a generic terminal error with no indication that the root cause was an incorrect discovery URL rather than an unreachable authorization server.