Codex disabled_tools: block Sume's paid MCP tools
List Sume's paid tool ids under disabled_tools in the Codex config.toml so the agent cannot call them, even on an API-key session that sees every tool.
Add a disabled_tools list to the Sume server entry in Codex's config.toml and name the paid tool ids you want out of reach, such as generate_video and music_create. Codex's MCP page calls disabled_tools the blocked-tools list, and Sume's docs list which hosted tool ids are paid.
Codex facts come from the Codex MCP page and Sume facts from MCP tools and gates and OAuth and API keys, all read 2026-09-30.
Why block tools on the client at all?
Sume's own gate depends on how you signed in. An OAuth session with only mcp:read sees read-only tools, and a paid call returns insufficient_scope. An API-key session sees the full hosted tool set, and the docs say paid and write calls still need an idempotency_key while wallet and admission act as the spend gate. A disabled_tools list is an extra layer for the API-key case, or for an OAuth session where you did turn Write on.
Which Sume tool ids are paid or write?
| Tool id | Class in the docs |
|---|---|
generate_image, generate_video | Paid, idempotency_key required |
music_create, tts_create, stt_create | Paid, idempotency_key required |
image_upscale_create, rmbg_create, video_upscale_create | Paid, idempotency_key required |
kling-motion-control_create | Paid, idempotency_key required |
avatars_create, avatar-videos_create | Paid, idempotency_key required |
jobs_cancel, assets_create | Write, idempotency_key required |
crawl_site | Write, unbilled utility |
What does the config look like?
Codex lists url as required for an HTTP server and offers bearer_token_env_var for a token held in an environment variable. Keep read tools such as jobs_status, jobs_wait and jobs_result enabled so the agent can still follow jobs.
[mcp_servers.sume]
url = "https://mcp.sume.com/mcp"
bearer_token_env_var = "SUME_API_KEY"
disabled_tools = [
"generate_image",
"generate_video",
"music_create",
"tts_create",
"avatars_create",
"avatar-videos_create",
]Does this replace OAuth read-only mode?
No. The docs prefer OAuth with mcp:read for read-only exploration, because those sessions are never shown mutating or paid tools. Treat disabled_tools as a second lock, not the first. Ask the agent to call tools_list to see what the Sume session offers, then compare it with what Codex exposes. Legacy allow_write and allow_paid arguments cannot bypass a missing mcp:write scope.
How do I test that the block works?
Ask the agent to call tools_list and compare it with the tools Codex exposes, and check balance_get and usage_get, the account read tools in the docs, before and after a session to confirm nothing was spent. Prefer generation_admission_preview before any expensive burst, and keep a fresh idempotency_key per paid submit so a retry does not create a second job.
Sources
Related posts
More in Developers
- Codex MCP enabled = false: pause the Sume server safely
Turn the Sume server off in Codex with enabled = false instead of deleting it, and rotate the API key if it ever showed up in logs or chat.
- Codex mcp_oauth_callback_port and the Sume OAuth login
Pin the Codex OAuth callback port for a remote Sume MCP login, and how the login flows from Codex to the Sume consent page on mcp.sume.com.
- Content Credentials after download: check the file you deliver
C2PA 2.2 defines Content Credentials and a separate Soft Binding API. Sume's docs do not say a downloaded output keeps one, so check the delivered file.
- Can I continue a Sume Agent Completion with thread_id?
Not yet. Every Agent Completion runs in a fresh thread, so a follow-up call cannot reuse thread_id. Pass earlier results back in the next request instead.
Written by Sume