Claude Desktop sends MCP transport requests to the server origin root, not the published resource path, after a successful OAuth exchange (external authorization server)

## Setup

- MCP resource server at `https://example.com/mcp` (Streamable HTTP, `mcp` Python SDK, FastMCP).
- Authorization server is **external** to the resource server — a separate OIDC provider on a different host/path (e.g. Keycloak at `https://auth.example.com/realms/x`), not the MCP server's own origin.
- RFC 9728 protected-resource metadata and RFC 8414 authorization-server metadata are both served correctly, at the correct path-inserted locations (`/.well-known/oauth-protected-resource/mcp`, etc.).

## What we observed

Connecting via Claude Desktop's custom connector flow:

1. Desktop reads our RFC 9728 metadata and completes the authorization/token exchange successfully (confirmed server-side: a valid access token is issued).
2. Desktop then reports **"no MCP server was found at the provided URL, or your account doesn't have access to it."**
3. Server-side, the resource path we published (`/mcp`) never receives a single request after the token exchange.
4. As a workaround, we additionally served the identical MCP transport at the bare origin root (`/`, same endpoint object as `/mcp`), leaving `/mcp` untouched. With that in place, the same Desktop client connects successfully end-to-end.

That last point is the load-bearing evidence: we no longer have the original raw access-log line quoting the exact request path (log rotation/container recreation on our side since first observing this), so we can't assert with byte-level certainty that Desktop requested `POST /`. What we can assert is that the client never reached the correct resource path at all, and that making the *origin root* answer identically to that path is what fixed the connection — which is consistent with the client resolving the resource to its origin rather than to the URL it was actually given.

## How this differs from #82

#82 (closed, not planned) and #716 describe Desktop/the legacy 2025-03-26 client flow deriving the **authorization endpoints** (`/authorize`, `/token`, `/register`) from the MCP server's own origin, discarding any path — which is what the 2025-03-26 spec revision actually told clients to do for the auth *base URL*, even though it's now superseded by RFC 9728/8414 discovery. We saw that too, but it's already covered by #82.

This report is about a **different** URL: the resource/transport URL itself, used for the actual JSON-RPC traffic after auth completes. No spec revision — including 2025-03-26 — says to discard the path there; its own worked examples send MCP requests to path-bearing URLs. So this looks like a distinct bug from the auth-endpoint one, closer in shape to #738 (requests to a multi-segment resource path go missing entirely) than to #82, but with the added detail that in our case the OAuth exchange completes fully before the transport request goes missing.

## Ask

- Can someone confirm whether Desktop's resource-URL handling is known to drop the path for any resource URL, or specifically for certain path shapes (single-segment `/mcp` in our case)?
- If useful, happy to reproduce on request, though we're not able to leave the aliasing workaround in place for a live re-test against a customer-facing server.

Related: #82, #716, #738.