Which Sume hosted MCP tools are read-only? 24 the docs label Read

Short answer

Sume's tools-and-gates page explicitly labels 24 hosted MCP tools as Read: 6 job tools, 3 asset tools, 2 text-to-speech source tools, 5 avatar tools and 8 crawl tools. A session with only the OAuth scope mcp:read sees read-only tools, and a call to a tool that changes data returns insufficient_scope.

The live registry is the real answer for your session. Always call tools_list and tools_schema, because the docs warn against assuming parity with the HTTP API.

Discovery tools outside that count

A second set exists for orientation: mcp_health, tools_list and tools_schema, plus account and catalog reads. The page groups these under meta, health, account and catalog rather than labelling each Read, which is why they are not in the 24. Under an OAuth read-only grant the quickstart treats mcp_health, tools_list, tools_schema, account_me and catalog_list as the useful first calls.

What is not read-only

Write tools need idempotency_key and mcp:write (or an API key): jobs_cancel, assets_create, assets_upload_url, assets_complete, and crawl_site, which is unbilled but still a write. The paid tools, such as the avatar create tools, additionally spend wallet funds.

There is no mcp:paid OAuth scope. Spend is gated by the wallet and admission, and by idempotency_key, optional dry_run and optional max_spend_usd.

Check it in your own session

Connect with OAuth and leave the Write toggle off on the consent page. Call mcp_health and confirm authenticated.auth_source is mcp_oauth. Then call tools_list: with Write off, only the read_only tools are listed, and the paid and write tools are hidden, not merely refused.

If you want agents to explore without any chance of spend, that is the safest configuration the docs describe. Grant mcp:write only for the session that must create.

• Read tools work under mcp:read, including crawl_scrape and jobs_list.
• Write and paid calls under mcp:read return insufficient_scope.
• A grant of write always includes read.

How to use the list

Treat the 24 as a floor for an exploration-only agent, and confirm it against tools_list on your own connection, since the registry can change between the docs and your session. A short allowlist in your agent harness that names only these tools adds a second guard on top of the OAuth scope.

If a task needs one write, such as cancelling a job, consider a separate session with mcp:write that exists only for that step.

Where the line blurs

Two cases surprise people. crawl_site sounds like the other crawl tools, but it is a write, so a read-only session will not list it. And jobs_cancel sits next to six read tools in the same jobs group yet changes state. Group names do not tell you the gate; the label on each tool does.

Avatar create tools are paid and are handled with admission checks. The CLI has its own matching gate, --confirm-paid, for the same avatar creates, so a script that works in one place does not silently spend in the other.

• Read the label, not the group.
• An API key gets the full tool set, so use a key only where you accept writes and spend.
• Use generation_admission_preview before any paid call you are unsure about.