Debug an MCP OAuth handshake in Postman against Sume's server

When a client cannot connect to an OAuth-protected MCP server, the failure message is usually vague. Postman gives you a way to watch the handshake instead. The Postman MCP requests page says MCP requests can be added to collections, and that for OAuth 2.1 servers Postman can "step through each phase of the handshake and identify where it breaks down," read 2026-10-03. It also says a server's configuration can be exported to set up an MCP host.

What Sume's side of the handshake looks like

The Sume OAuth page describes two metadata endpoints on the hosted MCP server: /.well-known/oauth-protected-resource/mcp and /.well-known/oauth-authorization-server. Consent happens on the MCP host at /oauth/authorize and then /oauth/consent, with PKCE. The scopes are mcp:read, which is required and read-only, and mcp:write, which is opt-in.

A workflow that isolates the problem

Create an MCP request in Postman for https://mcp.sume.com/mcp, run the OAuth flow, and note the phase that fails. If Postman completes the handshake and your agent client does not, the server is fine and the client's configuration is the problem. If Postman fails at the same phase, read that phase's response body before changing anything.

Once connected, call a read tool first. Then call a create tool with only mcp:read granted and confirm you get insufficient_scope. That proves the scope boundary works and tells you the fix is to request mcp:write, not to retry.

Keep spend out of a debugging session

The Postman page does not say how it stores credentials, so check your workspace sharing settings before you share a collection that holds a token.

• Call read tools such as mcp_health and balance_get while debugging.
• If you must test a create, use a preview (dry_run or generation_admission_preview) first.
• Send a fixed idempotency_key so a rerun cannot create a second job.
• Do not paste tokens into shared collections; export the server configuration only after removing credentials.