Sume MCP allow_write and allow_paid: accepted, not required, no bypass

Sume's hosted MCP server still accepts allow_write and allow_paid on tool calls, but neither flag is required and neither one can open a door. Access to tools that change data comes from the session: an OAuth grant that includes mcp:write, or an API key. A call from a read-only OAuth session with allow_write: true still returns insufficient_scope. The flags are kept for back-compat with older prompts and saved Format tips.

If your agent instructions say "always pass allow_write and allow_paid", you can delete that line. It does nothing useful, and it makes a model believe it has permission that it does not have.

Why are they legacy? A flag in a tool call is set by the model, and a model can set any boolean it likes, so the flag cannot prove that a person agreed. The decision now sits on the OAuth consent page, in front of the person and outside the model.

What actually gates a call

The two real gates are separate from the flags. The first is the credential. The second is the call itself: every write tool and every paid tool needs an idempotency_key, which the docs describe as a key for transport and deduplication, not as human approval.

Read the table from the top. The first row is the only one that grants access. Every other row either protects you from duplicates (the key), shows you the cost (the dry run), or limits the damage (the cap).

Why there is no paid scope

There is no mcp:paid scope. A paid call from a write session is checked against the wallet and generation admission, not against a third OAuth permission. That is why the docs recommend generation_admission_preview or dry_run before the first paid submit in a session, and why max_spend_usd is worth adding when an agent works without a person watching.

A useful habit for unattended work is to ask for a preview and a cap in the same call. dry_run makes no job, and max_spend_usd is checked against the estimate when you send it. An agent that omits the cap is not blocked by the server, so put the cap in the prompt or in a wrapper that you control.

Read-only sessions do not even see the tools

A read-only session has a second protection: it does not see write or paid tools in tools_list at all. The model cannot choose a tool that is not listed, which removes a whole class of mistakes. When a call to such a tool does arrive, for example from a stale prompt, it returns insufficient_scope.

The fix for that error is not a flag. Reconnect with Write turned on at the consent page, or switch the automation to an API key. Claude Code users can read the exact steps in the MCP quickstart.

You can verify a session in two calls. mcp_health shows the auth source, and tools_list shows whether generate_image and jobs_cancel are present. If they are missing, the session is read-only and no flag will bring them back.

A call without the legacy flags

For a clean, flag-free paid call, use the shape from the docs: a stable idempotency_key, a dry_run first, and an optional spend cap. The payload below is the avatar example from the tools page, trimmed to the gate fields.

{
  "idempotency_key": "avatar-create-2026-10-05-001",
  "dry_run": true,
  "max_spend_usd": 2,
  "payload": {
    "avatar_handle": "studio_presenter",
    "input": {
      "type": "prompt",
      "prompt": "A friendly studio presenter in neutral lighting"
    }
  }
}

Clean up the old prompts

Run it once with dry_run true and read the estimate. To submit, send it again with dry_run omitted or false, and keep the same idempotency_key only if you are retrying the same request. Use a new key for a new intention.

Finally, clean up old text. Search your system prompts, Format tips and agent skills for allow_paid. Removing it shortens the prompt and avoids a false sense of safety. The authoritative description is on MCP tools and gates and in MCP OAuth and API keys.

Teams that keep saved Format tips with the old flags in them do not have to rush. The flags are still accepted, so those tips keep working; they are just noise. Remove them the next time you edit the text, and test a read-only session to make sure the wording does not hint that a flag can unlock a tool.