MCP 2026-07-28 deprecates DCR: what Sume's MCP OAuth supports today

Sume's hosted MCP OAuth, as documented and coded on origin/main on 2026-10-04, still uses dynamic client registration with the authorization code flow and PKCE. The 2026-07-28 MCP revision deprecates dynamic client registration in favor of Client ID Metadata Documents, and I found no mention of those documents in Sume's OAuth docs or code. The open question is a client that supports only metadata documents.

What did the spec change?

The changelog lists three OAuth items: validation of the iss parameter (SEP-2468), an application_type field in client registration, and the deprecation of dynamic client registration (DCR) in favor of Client ID Metadata Documents. Each affects what a client sends before the first token request.

What does Sume do today?

Where do clients find the metadata?

Sume's MCP OAuth and API keys page publishes two endpoints: https://mcp.sume.com/.well-known/oauth-protected-resource/mcp and https://mcp.sume.com/.well-known/oauth-authorization-server. The protected-resource document names the MCP origin as the authorization server, and the resource audience is https://mcp.sume.com/mcp.

What should I do if my client wants a metadata document?

Use an API key. The OAuth page says remote MCP also accepts Authorization: Bearer <SUME_API_KEY> or an x-api-key header, and that path gives the full hosted tool set, with idempotency_key required on writes and paid calls. It is the supported route for automation that does not use OAuth.

Do not treat an OAuth token as a key. The page says an MCP OAuth token is not a Sume API key, and tells you not to mint API keys for hosted OAuth clients as a workaround. If a key leaks into logs or a chat, rotate it.

Interactive clients should keep using registration. The consent page shows Read locked on and Write off by default, so a read-only grant is one click.

What should I watch next?

Two things. First, whether your client library moves to metadata documents by default; if it does, test the sign-in against https://mcp.sume.com/mcp before you upgrade. Second, the iss check: the changelog says clients validate it, so any proxy that rewrites the authorization server origin could break a flow that worked before. Sume's docs say the authorization server is the MCP origin and the old www surface is deprecated, so keep every redirect on that origin.