OAuth metadata discovery fails for sub-path-mounted MCP servers when protected resource metadata is unavailable

[Educg550]

Inspector Version

• 0.21.1 (latest release)

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

1. 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).
2. Open Inspector and enter https://host/api/mcp/github/mcp as the server URL.
3. Initiate the OAuth flow and observe the metadata_discovery step.
4. 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.