Which login is my agent using? mcp_health auth_source on Sume MCP
Call mcp_health on the hosted Sume server to see the auth source of your session, then tools_list and account_me. Read-only OAuth and API-key sessions differ.
Call the mcp_health tool on the hosted Sume server. It reports the auth source of your session, which is mcp_oauth when you signed in with OAuth, and then tools_list and account_me show what that session can do. This is the fastest way to tell an OAuth session from an API-key session before an agent tries to spend money.
Why the auth source matters
The two logins behave differently on purpose. An OAuth session always has the mcp:read scope, and mcp:write is a separate opt-in at the consent screen. A read-only session that calls a write tool gets insufficient_scope. An API key sent as Authorization: Bearer $SUME_API_KEY or x-api-key gets the full tool set. If your agent can create things, you want to know which of the two it is using.
Four checks, in order
The docs list a short set of verification tools for exactly this check. Run them in this order, since each answers one question.
| Tool | Question it answers | What to look for |
|---|---|---|
| mcp_health | Is the server reachable and how am I signed in? | auth_source, which is mcp_oauth for an OAuth session |
| tools_list | Which tools can this session call? | Write tools missing means a read-only session |
| tools_schema | What does this tool take? | idempotency_key, dry_run and max_spend_usd on paid tools |
| account_me | Which account am I acting as? | The account, before anything is created |
Run the checks from a headless call
The script below asks Claude Code to run the first and last checks and print the raw results. It needs claude, jq and SUME_API_KEY, and the MCP config is built on the fly so nothing is stored. It calls only read tools.
jq -n --arg k "$SUME_API_KEY" '{mcpServers:{sume:{type:"http",url:"https://mcp.sume.com/mcp",headers:{Authorization:("Bearer "+$k)}}}}' > /tmp/sume-mcp.json
claude -p "Call mcp_health, then account_me. Print both raw results." \
--mcp-config /tmp/sume-mcp.json --output-format json | jq -r '.result'Check the OAuth case too
This run uses a key, so it should show the full tool set. To see the OAuth case, run claude mcp add --transport http sume https://mcp.sume.com/mcp without a header, then claude mcp login sume, and ask the agent to call mcp_health in an interactive session.
If a tool is missing
If a write tool seems to be missing, do not retry the call in a loop. A read-only session returns insufficient_scope for write tools, and the fix is to sign in again and approve mcp:write at the consent screen. There is no mcp:paid scope: paid tools sit behind mcp:write and then behind the gates, which are idempotency_key, dry_run, optional max_spend_usd, and wallet admission.
A rule worth keeping
Make this check part of the first turn of any agent that can spend money. It is free, it takes one call, and it prevents a whole class of confusing errors.
Sources
Related posts
More in Developers
- Which Omni input continues a scene: end frame, reference clip or edit?
Sume has no extend button. Continue an Omni scene with a last-frame image, a 3 s reference clip, or a video edit; this table says which, with costs per 10 s.
- What ends a Sume STT sentence segment: . ! ? and the Japanese marks
Sume ends a segment on . ! ? 。 ！ ？ … plus optional trailing quotes or closing parentheses; the corner bracket 」 and a fullwidth ） are not on that list.
- Which API key scope does each Sume webhook endpoint need?
The signing secret needs account:read, rotate and test deliveries need account:write, redeliver needs jobs:write or formats:write. Map each call to a key.
- Which Sume API requests count against the read rate limit?
Every GET and HEAD is a read, and so are POST /v1/generation/admission-preview and the MCP endpoint. Reads have their own per-key bucket, 40x the write one.
Written by Sume