Devin Local server-level MCP permission: what it means for Sume

Devin Desktop 3.5.17 added two server-level options to the MCP tool permission prompt. Before approving a whole server for Sume, know which tools it exposes.

5 min readSume
All posts

When Devin Local asks permission for a Sume tool, a server-level choice applies to everything that server can run, including paid generation tools if the session has them. Sume's safest setup is therefore a read-only OAuth grant plus per-tool approval, and a server-wide approval only on a grant without Write.

What did Devin Desktop add?

The Devin Desktop changelog (read 2026-10-03) lists under v3.5.17, dated July 17, 2026: "When prompted for an MCP tool permission in Devin Local, two additional server-level options are now offered". The entry does not name the two options, so this post does not guess their labels. It treats them as choices that cover a whole server rather than one tool.

Which Sume tools sit behind one server approval?

Sume's tools and gates page groups the hosted tools. What a server-wide approval covers depends on the grant, because the tool list itself changes with scope.

What a server-level approval would reach for Sume (docs, read 2026-10-03)
SessionVisible toolsPaid tools reachable
OAuth, Read onlyRead-only tools: jobs_list, assets_get, catalog_list, crawl_scrapeNo, they return insufficient_scope
OAuth, Read and WriteFull hosted setYes: generate_image, generate_video, tts_create, avatars_create
API keyFull hosted setYes

What is the safe way to approve Sume?

Match the approval to the grant. With a Read-only OAuth session, approving the whole server only opens read tools, which cannot spend. With Write on, prefer per-tool approval for the paid tools and keep the free ones, such as tools_list, jobs_status and balance_get, on a looser setting.

Nothing in Sume replaces your client's approval. The idempotency_key Sume requires on write and paid calls is, in the docs' words, a stable key for transport and dedup, not human approval. A server-level yes in the client is the only prompt that stands between an agent and a paid call.

How do I keep a spend bound even after a broad approval?

Put the bound into the call. Sume accepts dry_run=true for a cost preview and max_spend_usd as an optional cap that is enforced only when you pass it. Ask the agent to use both on the first paid call of a task, and to call generation_admission_preview before a burst of jobs.

{
  "idempotency_key": "launch-clip-2026-10-03-001",
  "dry_run": true,
  "max_spend_usd": 2
}
// Review the preview, then repeat without dry_run and with the same key.

What does Sume not do?

Sume does not know which approval mode your client uses. It also has no scope for paid calls: the docs are explicit that there is no mcp:paid. If an admin has to restrict the server, the related Devin post covers the allowlist, and the wallet and admission limits stay on Sume's side regardless of what the client approves.

Which Sume calls deserve a prompt every time?

Anything that spends or changes state. By Sume's tools page that is the paid generation family (generate_image, generate_video, music_create, tts_create, stt_create, upscale and background removal, avatars) and the write tools such as jobs_cancel, assets_create and crawl_site. Free reads such as tools_list, balance_get, jobs_status and assets_get are low risk and fine to auto-approve.

A practical split for a team: approve the read group per tool once, leave the paid group on ask, and have the agent always send dry_run=true first. When the estimate looks right, the person approves the real call.

What if my admin controls the server list?

Then the permission prompt is a second layer on top of the allowlist. The related Devin post on allowlists covers a Sume URL that is blocked until it is listed. Approving a server in the prompt does not override an admin block, and nothing on Sume's side changes either way.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume