MCP OAuth without DCR: client ID metadata documents and issuer checks

Dynamic client registration (RFC 7591) is deprecated in MCP 2026-07-28 in favor of Client ID Metadata Documents, and clients must now validate the iss value per RFC 9207 and key credentials by issuer. For a person connecting Claude, Cursor or Codex to a hosted media server, the practical result is the same as before: sign in once on the server's consent page. For a client author it means new checks. Source: the changelog, read 2026-10-03.

What changed for clients

Two changes land on the client side, and both are about not trusting a token that came from the wrong place.

What Sume documents

The Sume OAuth page describes the hosted flow: the client connects to https://mcp.sume.com/mcp, receives an OAuth challenge and protected-resource metadata, and goes to https://mcp.sume.com/oauth/authorize, then to the consent page on the MCP host. It exchanges the code with PKCE and calls the endpoint with the bearer token.

The docs do not say which registration method Sume accepts, so read the authorization-server metadata rather than assuming one. They name two public metadata endpoints for that. Consent shows Read locked on and a Write toggle that defaults to off; there is no mcp:paid scope.

curl https://mcp.sume.com/.well-known/oauth-protected-resource/mcp
curl https://mcp.sume.com/.well-known/oauth-authorization-server

Why keying by issuer matters here

The Sume docs say authorization_servers is the MCP origin and that www.sume.com remains a secondary, deprecated authorization-server surface that the metadata no longer advertises. A client that kept one token per server name could carry a token from an old issuer to the new one. Keying by issuer prevents that, and a changed iss becomes an explicit re-login instead of a silent failure.

The docs also state that an MCP OAuth token is not a Sume API key, and that you should not mint API keys for hosted OAuth clients as a workaround.

Checklist for a client author

• Fetch protected-resource metadata and take the authorization server from it, not from a hard-coded URL.
• Validate iss on the authorization response, and abort when it does not match the metadata.
• Store tokens under the issuer and the resource.
• Request the smallest scope first; a read-only grant is enough for discovery tools.
• Treat a missing token as a prompt to sign in, and never fall back to pasting a key into chat.