[BUG] 3P managedMcpServers ignores 401 WWW-Authenticate discovery metadata — cannot connect to a spec-compliant self-hosted MCP gateway

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

Environment

• Claude Desktop 1.19367.0, macOS 26.5 (Darwin 25.5.0)
• 3P mode (GA 2026-07-09), inferenceProvider: gateway with OIDC sign-in — working
• MCP servers delivered via MDM managedMcpServers (remote, transport: http)

Setup

Our MCP servers sit behind a self-hosted gateway (Pomerium) that implements the MCP
authorization spec (2025-11-25): RFC 9728 protected-resource metadata, its own authorization
server metadata, authorization-code + PKCE, and CIMD client admission. This gateway works
today with claude.ai custom connectors, Claude Code, and the mcp-remote bridge — all of
them follow the discovery flow and connect fine.

Expected

A managedMcpServers entry pointing at an OAuth-protected MCP server follows the spec flow:
401 → read WWW-Authenticate: Bearer resource_metadata=… → fetch PRM → run the OAuth flow →
connect. (Or: documentation of the intended alternative.)

Actual

The connector POSTs once, receives the 401, and gives up — parked with "Connection to server
failed." No discovery request, no /.well-known fetch, no registration attempt, no browser
window (verified in main.log and by watching the gateway's access logs). The Connect button
repeats the bare POST.

main.log:

[custom3p-mcp] connect failed — parked for retry { name: '<server>',
  error: 'Streamable HTTP error: Error POSTing to endpoint: {"error":"Unauthorized",...}' }
[custom3p-mcp] connection complete: 0 connected, 4 pending (retry via Connect button)

The gateway's 401 (curl, abridged):

HTTP/2 401
www-authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp"

$ curl -s https://mcp.example.com/.well-known/oauth-protected-resource
{"resource":"https://mcp.example.com","authorization_servers":["https://mcp.example.com"],
 "bearer_methods_supported":["header"],"resource_name":"Pomerium"}

Why the documented oauth block doesn't cover this

The configuration reference's oauth object on managedMcpServers presumes a
pre-registered static client at the authorization server. MCP-gateway products that act
as the AS (Pomerium's MCP mode, and others) admit clients via CIMD or DCR only — there is
no static-inbound-client facility to register against. And a 3P deployment by definition has
no claude.ai identity, so the CIMD path claude.ai-family clients use is unavailable. Net
effect: a 3P fleet cannot connect to a spec-compliant self-hosted MCP gateway by any
documented configuration.

Questions / requests

1. Is MCP-spec authorization discovery (RFC 9728) with CIMD and/or DCR planned for

managedMcpServers? This would make 3P Desktop behave like every other Claude MCP client
against the same gateway.

1. If not: what is the intended pattern for 3P customers whose MCP servers are behind a

spec-compliant OAuth gateway? E.g., is the expectation that the gateway accepts
IdP-issued access tokens as bearers with the oauth block pointed at the enterprise
IdP? If so, documenting that shape (and the token-audience expectations) in the 3P
configuration reference would help a lot.

1. Small related ask: when a managed server's connect fails on a 401 that carries

WWW-Authenticate discovery metadata, surfacing that in the error UI ("server requires
OAuth; no oauth configuration provided") would have saved us a day of gateway-side
debugging — the current "Connection to server failed" reads as a network error.

Context for prioritization: this is the flagship 3P combination — an enterprise that adopted
3P because of data-plane requirements is exactly the enterprise that self-hosts its MCP
servers behind a gateway. Happy to provide full logs, gateway configs, or a test environment.