Zed tool permissions for Sume: mcp:server:tool keys

Zed's agent.tool_permissions.default setting takes confirm, allow or deny, and confirm is the default, so every Sume tool call prompts you unless you change it. For finer control, Zed documents a key format of mcp:<server>:<tool_name>, so a server named sume and a tool named jobs_status gives mcp:sume:jobs_status. Allow the free reads individually and leave generation on confirm.

What are the three default modes?

According to the Zed docs, confirm prompts for approval before running any tool action, allow auto-approves, and deny blocks all tool actions.

Which Sume tools are safe to allow?

Sume's docs list free reads you can allow one by one: mcp_health, tools_list, tools_schema, balance_get, catalog_list, jobs_status, jobs_get, jobs_result and assets_get. Paid tools include generate_image, generate_video, music_create and tts_create; leave them on confirm so you see the call and its arguments.

How should the server be configured?

Under context_servers, a remote entry takes url and optional headers. With no Authorization header Zed starts the OAuth flow; Sume's OAuth grants read-only unless you tick Write on its consent page. Name the entry sume so the permission keys above match.

Confirmation in Zed is a client-side prompt. Sume's separate gates still apply: paid calls need an idempotency_key, dry_run previews cost, and max_spend_usd caps a call when you pass it.

What does a sensible rule set look like?

Keep agent.tool_permissions.default at confirm. Then add per-tool rules for the free reads you call constantly, using the mcp:sume:<tool> pattern from Zed's page. Check Zed's documentation for the exact rule syntax in your version, because this page only confirms the key format and the three default modes.

For paid tools, the confirmation prompt is your last human checkpoint, because Sume's idempotency_key is a dedup mechanism and not an approval. Read the prompt for the tool name, any dry_run flag and max_spend_usd before you accept.

If you want certainty that the agent cannot spend at all, connect with OAuth and leave Write off at consent. Then write and paid tools are not available to the session, whatever the Zed permission mode says.

Before you rely on any of this in a team setting, test it once end to end with a throwaway prompt. Call mcp_health, call tools_list, and run one dry_run against a paid tool. Compare the tool count with what you expected for your credential. If a read-only OAuth session lists more than you expected, or a key session lists fewer, stop and recheck which credential the client is actually sending. Sume's mcp_health response reports the auth source, which settles the question quickly without guessing.