OAuth completes and issues a token, but Claude.ai never calls the MCP resource endpoint afterward

**MCP server URL:** https://redacted-domain.example/api/mcp _(domain redacted for privacy — happy to share the real URL and reproduction identity privately if a maintainer needs it to correlate logs)_

**Where does the issue occur?** When auth finishes and redirects back to Claude.ai

**Transport used:** streamable-http

**Client registration type:** Dynamic Client Registration (DCR)

**SSE only: expected status code for POST?** Not applicable (server does not use SSE)

**When did you last reproduce this?** 2026-08-17 12:25 PM PDT

**Browser and OS:** Chrome on macOS

## Describe the issue

Adding this MCP server as a custom connector reports success through the entire OAuth flow (Cognito login completes, our bridge issues a valid access token), but Claude.ai then never calls the MCP resource endpoint (`POST /api/mcp`) at all — not even once, authenticated or unauthenticated. The connector setup then fails with a generic error claiming the account was authorized but no MCP server could be found at the URL.

This is fully reproducible: 4/4 attempts (including one full "remove connector, add fresh") show the identical pattern in our server logs — `/authorize`, the Cognito login, and `/oauth/token` all complete successfully every time, but `/api/mcp` receives zero requests afterward.

Our server implementation is a close copy of another MCP server we already run successfully as a Claude.ai custom connector (same OAuth-bridge-in-front-of-Cognito pattern, same `@modelcontextprotocol/sdk` `McpServer` + `WebStandardStreamableHTTPServerTransport`, same response shapes) — that other connector works fine. The two share the same underlying Cognito user pool and hosted UI domain, but use distinct OAuth app clients (distinct `client_id`s) and distinct issuer origins in their `.well-known/oauth-authorization-server` metadata. We haven't been able to determine from our side why the client stops after obtaining a token instead of calling the resource server.

## Issue details

Four attempts, all producing a Claude.ai error dialog of the form:

> Your account was authorized, but no MCP server was found at the provided URL, or your account doesn't have access to it. Check the server URL or your access, then try again.

Reference IDs shown, in order of occurrence:
- `ofid_4640e56853942d6f`
- `ofid_12c9e725f512d494`
- `ofid_ca3934a972b4f4bc`
- `ofid_b226c31fd3b1ec60` (most recent, after fully removing and re-adding the connector)

## Expected behavior

After the OAuth flow completes and Claude.ai has a valid access token, it should call `POST /api/mcp` (MCP `initialize`) with `Authorization: Bearer ` to complete the connection. Instead, no such call is ever made — the connector fails before attempting to use the token it just obtained.

## Logs from your server

Server-side logs for the most recent (4th) attempt, 2026-08-17 12:25 PM PDT — every one of our OAuth endpoints fires exactly once and succeeds; `/api/mcp` never appears:

```
[mcp-bridge] authorize: all params = { scope: 'mcp', code_challenge: 'A6BUeVrxLNyillzhQ6TPCqs1Gvs_sYNY7bgd4q_ib-4', redirect_uri: 'https://claude.ai/api/mcp/auth_callback', code_challenge_method: 'S256', response_type: 'code', client_id: 'mcp-bridge-client', state: 'y4R0gt9uPnh5LgzNix02advoFgfbnhvFtMTTcyP5gd0' }

[mcp-bridge] cognito-callback: resolved identity { sub: 'redacted@example.com', name: 'REDACTED' }

[mcp-bridge] token: body keys = [ 'grant_type', 'code', 'client_id', 'code_verifier', 'redirect_uri' ] grant_type = authorization_code resource = undefined
```

(No `resource` parameter is sent by the client at any point in the flow — RFC 8707 resource indicators are not used.)

The prior 3 attempts show byte-for-byte the same pattern (different `state`/`code_challenge` values per attempt, same fields, same absence of any subsequent `/api/mcp` call). No errors, no 5xx, nothing — our resource endpoint's route handler logs unconditionally on every single invocation (before even checking for an Authorization header), and it simply was never invoked.

## Additional context

- Dynamic Client Registration response we return (static, single-client shim): `{ client_id: 'mcp-bridge-client', token_endpoint_auth_method: 'none', grant_types: ['authorization_code', 'refresh_token'], response_types: ['code'] }`.
- `/.well-known/oauth-authorization-server` for this resource: issuer `https://redacted-domain.example`, `authorization_endpoint`/`token_endpoint`/`registration_endpoint` all under `https://redacted-domain.example/api/mcp/oauth/*`, `token_endpoint_auth_methods_supported: ['none']`, `scopes_supported: ['mcp']`.
- `/.well-known/oauth-protected-resource`: `{ resource: 'https://redacted-domain.example/api/mcp', authorization_servers: ['https://redacted-domain.example'] }`.
- Confirmed via manual testing that arbitrary requests (including unauthenticated ones) reach `/api/mcp` fine — we get our own expected 401 response with the RFC 9728 `WWW-Authenticate` header back immediately. No WAF or CDN-level blocking is in front of this endpoint (verified: no AWS WAF WebACL exists on this account/distribution at all).
- We also run a second MCP connector on a different domain, sharing the same Cognito user pool and hosted UI domain (`*.auth.us-east-1.amazoncognito.com`) but a distinct OAuth app client and distinct issuer/metadata — that one has worked correctly as a Claude.ai custom connector for some time. This new one, added the same way, exhibits this failure consistently.