One MCP server, three connectors: Claude, ChatGPT, Grok

Claude, ChatGPT, and Grok all speak MCP and all use OAuth 2.1 with the same discovery machinery: protected-resource metadata (RFC 9728), authorization server metadata (RFC 8414), PKCE, and Streamable HTTP. Build the flow once — the connector checklist and the Auth0 proxy pattern both apply to all three — then handle the per-client differences below.

The differences that actually matter

	Claude (claude.ai)	ChatGPT	Grok (grok.com)
Where users add it	Settings → Connectors	Settings → Connectors (developer mode)	grok.com/connectors → New Connector → Custom
Client identification	Dynamic client registration	CIMD, DCR, or a predefined client	OAuth flow in-app; register via DCR
Redirect URI	https://claude.ai/api/mcp/auth_callback and https://claude.com/api/mcp/auth_callback	https://chatgpt.com/connector_platform_oauth_redirect	Capture from the DCR request (see below)
DCR frequency	Per connector setup	Once per MCP server connection, then the registered client is reused	Per connector setup

Redirect URIs: allow what registers, don’t hardcode

The single most common cross-client failure is a redirect-URI allowlist written for one client. Claude’s callback is not ChatGPT’s (connector_platform_oauth_redirect), and clients occasionally append callback IDs or paths — the full derived redirect_uri must be honored, not just the base host.

The robust pattern for a DCR endpoint that serves all three:

1. Accept the registration and store the exact redirect_uris the client sends.
2. Validate the host against a short allowlist of client origins: claude.ai, claude.com, chatgpt.com, openai.com, grok.com, x.ai.
3. At /authorize time, verify the requested redirect_uri exactly matches one stored for that client — then let it through.

This also future-proofs you: when a client changes its callback path (it has happened), your server keeps working without a redeploy.

ChatGPT: CIMD is preferred, DCR is the fallback

ChatGPT identifies itself three ways, in order of preference:

1. Client ID Metadata Documents (CIMD) — the client presents a URL as its client_id; your authorization server fetches that URL for the client’s metadata. Support it if your stack can.
2. Dynamic client registration — used when you advertise a registration_endpoint and CIMD isn’t available. ChatGPT registers once per connection and reuses the client.
3. A predefined OAuth client — you paste a client ID/secret into the connector configuration. This is the escape hatch when your identity provider can’t do either of the above.

If you built the thin DCR proxy, option 2 works as-is — just add ChatGPT’s redirect to the allowed origins.

Grok: same flow, younger surface

Grok’s “Bring Your Own MCP” (grok.com/connectors → New Connector → Custom) takes your MCP server URL and runs the OAuth flow inside Grok. The discovery sequence is the standard one; the practical differences:

• Don’t hardcode a Grok callback URL from a blog post (including this one). Log the redirect_uris in your DCR endpoint’s requests the first time you connect, and let the allow-what-registers pattern above handle it.
• The DNS and TLS pre-flight rules from the failure map apply unchanged: a public hostname and a publicly-trusted certificate, no tunnels with non-public DNS.

One test matrix

For each client, run the same four checks from the checklist — 401 probe, both metadata documents, DCR — then connect for real. Log every request your server sees during the first connection of each client; the logs are the authoritative documentation of what that client actually does, and they’re what you’ll want when one of the three changes behavior.