claude mcp login skips the 401 / WWW-Authenticate discovery step and only probes the RS own PRM path

What happened

When authorizing an HTTP MCP server that delegates discovery to a separate Authorization Server, running:

claude mcp add --transport http <name> <url>
claude mcp login <name>

fails to discover the OAuth metadata. claude mcp login appears to look for Protected Resource Metadata directly at the resource server's own /.well-known/oauth-protected-resource path, without first making a request that hits 401 and reading the resource_metadata pointer from the WWW-Authenticate header.

Expected (per spec)

Per the MCP authorization spec and RFC 9728, the authoritative discovery entry point is the 401 response's WWW-Authenticate: Bearer resource_metadata="…" pointer. A resource server is allowed to host its PRM elsewhere (e.g. on the AS) and advertise it via that header. claude mcp login should perform the protected-resource request first, consume the WWW-Authenticate pointer, and follow it — rather than assuming the RS hosts PRM at its own well-known path.

Workaround

Inserting claude mcp get between add and login triggers an actual request to the RS, which hits 401 and caches the WWW-Authenticate pointer; login then succeeds:

claude mcp add --transport http <name> <url>
claude mcp get  <name>     # triggers the request → 401 → caches the resource_metadata pointer
claude mcp login <name>    # now discovery works

Environment

• claude CLI version: 2.1.193 (Claude Code)