Gemini CLI MCP tool names: write policy rules for Sume's paid tools

Gemini CLI namespaces every MCP tool as mcp_{serverName}_{toolName}, so with a server named sume, Sume's generate_image appears as mcp_sume_generate_image. To control it, write a policy rule in ~/.gemini/policies/*.toml with mcpName = "sume" and toolName = "generate_image", using the simple tool name rather than the long form.

The naming and the rule format are from Gemini CLI's pages MCP servers and Policy engine, read on 2026-10-02. Sume's tool ids are from MCP tools and gates.

What is the tool name Gemini CLI shows for a Sume tool?

Gemini CLI's page says MCP tools get an automatic mcp_{serverName}_{toolName} prefix to prevent collisions and to enable policy-based access control. Sume's live tool ids are underscore names, so the two joined together look like mcp_sume_jobs_wait. The page warns that the policy engine splits on the first underscore after mcp_, and advises avoiding underscores in server names: use my-server, not my_server.

That matters for Sume in one way: name the server sume, which has no underscore, and the split lands where it should. A server named sume_prod would be read as server sume with a tool called prod_generate_image.

How do I write the rule?

Gemini CLI's policy page recommends mcpName with toolName, and says toolName should be the simple tool name, not the fully qualified one. A rule has a decision: allow runs the tool automatically, deny blocks it and removes it from the model's memory, and ask_user prompts. Each rule also carries a priority; the page's example uses 200. I have not read how priorities resolve ties, so test the result with a read call and a paid call before trusting the file.

# ~/.gemini/policies/sume.toml
[[rule]]
mcpName = "sume"
toolName = "tools_list"
decision = "allow"
priority = 200

[[rule]]
mcpName = "sume"
toolName = "jobs_wait"
decision = "allow"
priority = 200

[[rule]]
mcpName = "sume"
toolName = "generate_image"
decision = "ask_user"
priority = 200

How do I add and check the server first?

Gemini CLI's page lists gemini mcp add <name> <command>, gemini mcp list to see servers and their connection status, and gemini mcp enable and disable to toggle a server without removing it. A remote server takes httpUrl for streamable HTTP, which is what Sume's endpoint speaks, and headers for an API key; url is the SSE form. For OAuth, the page says the CLI detects the need from a 401 response and you manage it with /mcp auth <serverName> inside a session.

After it connects, ask Gemini to call mcp_health. That confirms the endpoint and the auth source. Then run tools_list and compare the names with the table above, so you know the exact strings your rules must match.

Which Sume tools should stay prompted?

Anything that spends or mutates. Sume's inventory marks paid creates (generate_image, generate_video, music_create, tts_create, stt_create, avatars_create) and write tools (jobs_cancel, assets_create) as needing an idempotency_key. Reads such as jobs_status, catalog_list and balance_get are safe to allow. Keep the paid ones at ask_user for interactive work; headless runs behave differently.

Where does Sume's own safety fit in?

The policy is the client's gate. Sume has its own. Read tools are always free to call. Paid and write tools need an idempotency_key, dry_run=true previews the cost, and max_spend_usd caps a call when you provide it. An OAuth session with Write off never lists paid tools at all, so a rule for generate_image would have nothing to match. Use both layers: Sume's scope decides what exists, your policy decides what runs unprompted.

What does this not cover?

Policies are Gemini CLI features and may change with its releases. Sume does not read your policy files, and trust: true on the server entry bypasses confirmation for that server entirely according to Gemini CLI's page, which makes it a poor fit for a server that can spend money. Wildcards such as mcpName = "*" apply across servers, so a broad allow rule can cover Sume without naming it.