MCPJam auth debugger on Sume's MCP host: what each step returns

If you run MCPJam's OAuth debugger against https://mcp.sume.com/mcp, expect a public-client, authorization-code flow with S256 PKCE, a resource value that must match Sume's MCP endpoint, and a one-hour access token with no refresh grant. The debugger describes itself as guided conformance checks for MCP OAuth, so the useful question is what a clean Sume run should look like and which rows tell you something is wrong on your side.

MCPJam's facts come from its documentation, read on 2026-10-11. Sume's facts come from its OAuth and API keys page and from the OAuth metadata builder in the Sume repository (packages/mcp-oauth), which I read for this post. I did not run the debugger against production, so the right-hand column states what the metadata code and docs say, not a captured result.

What does MCPJam check?

MCPJam's page says its OAuth Debugger runs guided conformance checks across protocol versions 03-26, 06-18, 11-25 and 2026-07-28, and that the checks cover dynamic client registration (DCR), pre-registration and client ID metadata documents (CIMD). The same page says you can start the Inspector with a prefilled server URL, bearer token and starting tab through CLI flags, and that the web app at app.mcpjam.com handles HTTPS servers only.

That last point suits Sume, whose endpoint is HTTPS. A localhost callback is also accepted on Sume's side: its redirect rule allows any https URI, and http only for localhost and 127.0.0.1.

What should each step show against Sume?

The table lines up the OAuth steps with what Sume's code and docs define. Treat it as a checklist to compare against your own run.

Which results are surprises, and which are by design?

Three results look like failures but are design choices. First, the metadata lists only S256 for PKCE, so a client that sends plain is refused with an invalid-request error. Second, grant_types_supported is authorization_code alone, so there is no refresh-token step to pass; when the hour is up, the client signs in again. Third, token_endpoint_auth_methods_supported is none: Sume treats clients as public, so a debugger run that tries to supply a client secret has nothing to present it to.

The CIMD row deserves care. Sume's metadata builder lists a registration endpoint and no client-metadata-document field, so I would not assume that row passes. Read the result, and treat a CIMD miss as a gap in what that single check measures, not as a Sume outage. If a client cannot register, the docs offer the API-key route for automation instead.

How do scopes and the resource value show up?

Sume supports mcp:read and mcp:write only. An authorize request with another scope returns invalid_scope, and asking for write always includes read. The resource parameter is required and must be one of Sume's allowed MCP resources; anything else gets invalid_target. In a debugger run, a wrong resource is a likely reason for a failure at the authorize step, because many OAuth libraries only add it if you set it.

After sign-in, the consent page on the MCP host shows Read locked on and Write off by default. A debugger token without write will pass tools_list and fail generate_image with insufficient_scope; that is the read-only session working. Re-run the flow with Write on if you want to test a paid tool, and use dry_run=true so the test costs nothing.

What do I do after a clean run?

With a good token, use MCPJam's manual tool calls for mcp_health and tools_list, which Sume's quickstart lists as the first read-only checks. Confirm that mcp_health reports mcp_oauth as the auth source. Then keep the hour in mind: an access token is not a Sume API key, it expires in 3600 seconds, and it should never be pasted into a ticket or a chat.