Zed tool permissions: confirm by default, rules per Sume tool
Zed confirms every tool action by default and can allow or deny one MCP tool by name. Keep Sume's paid generators on confirm while reads run freely.

Zed's agent asks for approval before any tool action by default, and it can allow or deny individual MCP tools. For a Sume server named sume, that means you can let read tools run and keep paid generators on confirm or deny. The rule key has the form mcp:<server>:<tool_name>.
What Zed documents
The per-tool key is how you write one rule for one Sume tool without changing the default for everything else. Zed documents the pattern with a GitHub example; the same shape applies to any MCP server you name in your settings, so a Sume rule would read mcp:sume:<tool_name> if you named the server sume.
Zed's docs also say that a remote server with no Authorization header triggers the standard MCP OAuth flow. With Sume that means a browser sign-in on the MCP host, and by default the session is read-only.
| Setting | Values | Meaning |
|---|---|---|
| agent.tool_permissions.default | confirm (default) | Prompt before every tool action |
| agent.tool_permissions.default | allow | Auto-approve tool actions |
| agent.tool_permissions.default | deny | Block all tool actions |
| Per-tool key | mcp:<server>:<tool_name> | Example in the docs: mcp:github:create_issue |
Mapping it onto Sume's tools
Sume's hosted tools split cleanly. Reads such as tools_list, catalog_list, balance_get, jobs_list and jobs_status spend nothing. Paid tools such as generate_image, generate_video, tts_create and avatars_create need an idempotency_key and draw on your wallet. The tools and gates page lists every tool by group.
A sensible Zed setup is a default of confirm, with explicit allow rules for the read tools you call constantly. Keep the generators on confirm.
- Name the server
sumeincontext_serversso rule keys stay short. - Confirm the tool id with
tools_listbefore writing a rule; a typo means the tool falls back to the default. - Do not set
allowglobally when the session has Write on or uses an API key.
Two layers, not one
Zed's rules are on your machine. Sume's gates are on the server. If you connect with OAuth and leave Write off, the paid tools never appear, which makes a per-tool rule unnecessary for them. If you connect with an API key, the full tool set appears and your Zed rules are the only human checkpoint.
The tradeoff is convenience: more allow rules mean fewer prompts and more reliance on max_spend_usd and dry_run to bound a bad call.
Sources
Related posts
More in Integrations
- Approval gate before posting AI video: verify the Sume webhook
Hold every AI video for human review before it posts. A Node verifier for Sume's signed job webhooks that refuses an empty secret, plus the review steps.
- Cline autoApprove for Sume: list only the read-only tools
Cline's remote MCP entry supports an autoApprove array. Put Sume's read tools in it and keep paid creates such as generate_image on manual approval.
- Azure DevOps remote MCP is GA: run it beside Sume's hosted MCP
Azure DevOps remote MCP went GA in sprint 278 with Foundry and Copilot Studio support. Here is how to hold it and Sume's MCP with separate credentials.
- BigQuery product table to Sume bulk queues and a queue map
Read active SKUs from BigQuery, cast columns to plain JSON types, create one Sume bulk queue per 100 rows, and stream queue id, index and SKU to a map table.
Written by Sume