account_me then balance_get: two reads before an agent spends

Two free reads should come before any paid submit from an unattended agent on Sume's hosted MCP: account_me to confirm which workspace the credential is bound to, and balance_get to read the available USD wallet. Neither spends anything, and both work under OAuth mcp:read. They answer different questions, and neither is a cost estimate: for that, use generation_admission_preview or dry_run=true.

The tool behavior below comes from the tool contracts in the Sume MCP server and from MCP tools and gates, read on 2026-10-03.

What each read is for

account_me returns non-secret account and workspace context for the credential that made the call, whether that is an API key or an OAuth token. It is how an agent confirms it is scoped to the workspace the operator intended. Sume keys are already bound to a workspace, so there is no tool to list or switch workspaces, and an agent should never ask the user for a workspace id.

balance_get returns the available wallet balance in USD. It is the check to make before a burst of paid calls, or when a submit might be refused for funds. It is not a ledger and it is not a forecast of what one request will cost.

The order an agent should follow

The pattern is short enough to put in a system prompt. First account_me, and stop if the workspace is not the expected one. Then balance_get, and stop or shrink the plan if the wallet cannot cover the work. Then a preview of the specific calls. Only then submit, each with its own idempotency_key.

Balance can change between the read and the submit, so the balance check informs the plan but does not replace the gates on the submit itself. A paid call can still fail with 402 insufficient_credits before provider work starts, and the agent should treat that as a stop condition rather than retry with a new key.

What stays outside these two reads

Neither tool describes plans, top-ups or concurrency. Concurrency is plan-based and is not raised by prepaid top-ups, and queue capacity follows from it, so a full queue shows up as 429 queue_full, not as a balance problem. The generation admission page documents those limits.

For cost after the fact, usage_get reads the ledger, and with a thread, run or job id it returns what was actually debited. Use it to close the loop: balance before, usage after. Do not add up ledger rows by hand; held and refunded amounts appear in rows without being spend.