Skip to content

fix(client): align displayed OAuth metadata URL with the fetched URL (#1166)#1253

Open
MukundaKatta wants to merge 1 commit intomodelcontextprotocol:mainfrom
MukundaKatta:fix/oauth-display-url
Open

fix(client): align displayed OAuth metadata URL with the fetched URL (#1166)#1253
MukundaKatta wants to merge 1 commit intomodelcontextprotocol:mainfrom
MukundaKatta:fix/oauth-display-url

Conversation

@MukundaKatta
Copy link
Copy Markdown

Summary

Fixes #1166.

The OAuth Metadata Discovery panel showed the base /.well-known/oauth-protected-resource URL as the source of the resource metadata, but the MCP TypeScript SDK actually fetches the path-aware variant first (e.g. /.well-known/oauth-protected-resource/mcp for an MCP server URL like https://staging.mcp.cloudflare.com/mcp). The displayed source URL therefore disagreed with the metadata body shown right below it, which is confusing when debugging OAuth.

This change mirrors the SDK's path-aware discovery in a new getProtectedResourceMetadataDiscoveryUrl helper (a sibling of the existing getAuthorizationServerMetadataDiscoveryUrl) and uses it in OAuthFlowProgress.tsx so the displayed URL matches the URL that is actually requested.

Behavior

For serverUrl = https://staging.mcp.cloudflare.com/mcp:

  • Before: panel said the metadata came from https://staging.mcp.cloudflare.com/.well-known/oauth-protected-resource, but the displayed body was actually fetched from .../oauth-protected-resource/mcp.
  • After: panel says https://staging.mcp.cloudflare.com/.well-known/oauth-protected-resource/mcp, matching the SDK's path-aware request.

For serverUrl = https://example.com (no path), the displayed URL is unchanged.

Notes

  • Pure display fix. No change to fetch behavior — the SDK keeps doing path-aware discovery with a fallback to root.
  • If the SDK's path-aware request 404s and it falls back to root, the displayed label will be a tiny step ahead of the fallback URL, but for the common success case (and for the failure case described in the issue) the displayed URL now matches what was fetched.

Test plan

  • Unit tests for getProtectedResourceMetadataDiscoveryUrl covering root, sub-path, and trailing-slash inputs.
  • Manual: npm run dev, point Inspector at an MCP server with a non-root path (e.g. https://staging.mcp.cloudflare.com/mcp), open the Metadata Discovery panel, confirm the displayed source URL matches the request the SDK actually makes.
…odelcontextprotocol#1166)

The Metadata Discovery panel rendered the base `/.well-known/oauth-protected-resource` URL even when the MCP TypeScript SDK actually fetched the path-aware variant (e.g. `/.well-known/oauth-protected-resource/mcp` for an MCP server URL like `https://staging.mcp.cloudflare.com/mcp`). This caused the displayed source URL to disagree with the metadata body shown right below it, making OAuth debugging confusing.

Mirror the SDK's path-aware discovery in a new `getProtectedResourceMetadataDiscoveryUrl` helper (a sibling to the existing `getAuthorizationServerMetadataDiscoveryUrl`) and use it in `OAuthFlowProgress` so the displayed URL matches the URL that is actually requested.

Fixes modelcontextprotocol#1166
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant