Sume MCP with Write off: what an OAuth agent can still do

An agent on hosted Sume MCP with Write left off can still read: it can list and fetch jobs, read assets, browse the catalog and scrape web pages. It cannot create assets, cancel jobs or generate images and video. Those calls return insufficient_scope. This is the default after OAuth, because the consent page shows Read locked on and the Write toggle off.

Sorted by what works

Sume's quickstart and tools-and-gates pages give examples for each side of the line. The table repeats them; call tools_list for the live set in your session.

Visibility is the first line of defense

The docs say hosted MCP hides the tools that change data and the paid tools until the session has mcp:write or an API key. So with Write off, tools_list shows only the read-only tools, and a model that never sees generate_video cannot suggest calling it. If a stale prompt names a hidden tool anyway, the call returns insufficient_scope.

This makes read-only OAuth a sensible default for exploring. There is no mcp:paid scope, so the choice is one switch: Write off for exploration, Write on to let the agent create.

A five-step read-only tour

Playbook A on the tools-and-gates page is a good first run:

• Connect to https://mcp.sume.com/mcp with OAuth and keep Write off.
• Call mcp_health and confirm authenticated.auth_source is mcp_oauth.
• Call tools_list; with Write off, only read_only tools appear.
• If you need more context, call catalog_list, balance_get and jobs_list.
• Stop before any tool that changes data.

When to turn Write on

Reconnect with Write when the task is to generate. A write grant always includes read. After that, paid calls still need an idempotency_key, and spend is governed by wallet and admission, so use dry_run and max_spend_usd for the first call. The legacy allow_write and allow_paid arguments are accepted but are not required, and they cannot bypass a missing mcp:write scope.

If you would rather not click through consent, an API-key session sees the full tool set from the start. Choose that deliberately, and apply the same per-call caps.

What read-only is good for

Plenty of useful agent work needs no write access. An agent can check what the account can do (catalog_list), see what is already running (jobs_list), inspect a finished asset (assets_get), and pull a web page into the conversation (crawl_scrape) to base a script on. It can also review spending with balance_get before anyone enables Write.

A practical pattern is two server entries: a read-only OAuth entry that is always on, and a second entry with Write that you enable only for the generating session. That way the everyday chat cannot spend, and a model that wants to generate has to be reconnected with the Write toggle on.