MCP authorization spec: 6 requirements vs what Sume documents

Hosted Sume MCP documents most of what the current MCP authorization specification asks of a server: protected resource metadata, an authorization server it points to, PKCE, an audience bound to https://mcp.sume.com/mcp, bearer tokens in the Authorization header, and a scope error for tools a session cannot call. The Sume docs do not say whether the server accepts a resource parameter or which client registration methods it supports, so those two rows are open for you to test.

The specification page was read on 2026-10-09. It says authorization is optional for MCP servers, that HTTP transports should follow it, and that MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728). It also says clients must send the RFC 8707 resource parameter on both the authorization and token requests, and must never put access tokens in the query string.

Requirement by requirement

The right column quotes only what the Sume docs state, read 2026-10-09.

The scope behavior

The spec says a server should answer an under-scoped call with 403 and a WWW-Authenticate header carrying error="insufficient_scope". Sume's docs say a read-only session that calls a write or paid tool gets insufficient_scope; they do not state the HTTP status. Sume's scopes are mcp:read, required, and mcp:write, opt-in on the consent page, with no mcp:paid scope. A grant of write always includes read.

The spec also tells clients to repeat the request with a bigger scope set only a few times. If you build a client, apply the same limit to the Sume step-up: one re-consent, then stop.

A short test plan

Run these four checks against your own client rather than trusting any summary.

• Fetch the two well-known URLs and confirm the audience matches what your client sends.
• Connect with Write off and confirm tools_list shows only read tools.
• Call one paid tool and record the exact status and body of the refusal.
• Check that the client sends the token only in the Authorization header.

Why the open rows matter

Registration is where interoperability usually breaks. The spec lists three ways for a client to get a client ID: a client ID metadata document, pre-registration, or dynamic client registration, and it marks dynamic registration as deprecated and kept for older servers. A hosted server does not have to support all three, and the Sume docs only describe the end-to-end flow from the user's side. If your client fails at the registration step, capture the exact error and compare it with the list of methods the client supports.

The resource parameter is the other row to test. The spec says clients must send it regardless of whether the authorization server supports it, so a conforming client will send it either way. Sume documents the audience as https://mcp.sume.com/mcp; use that exact string, without a trailing slash or fragment, wherever your client lets you set the resource.