Mistral Vibe tool globs: keep Sume to read-only tools

Because Mistral Vibe can only use a Sume API key, and an API-key session sees paid tools, the way to get a read-only Sume in Vibe is to allowlist read tools by glob. Vibe names MCP tools {server_name}_{tool_name}, so a server named sume exposes sume_jobs_list and, if you let it, sume_generate_video. Its config.toml supports enabled_tools and disabled_tools patterns plus per-tool permission settings, including ask (read 2026-10-03).

The Vibe pattern syntax is on its MCP servers page; the tool list is from MCP tools and gates. Confirm exact glob matching in Vibe before trusting it, since this post only shows the documented example shape.

Which Sume tools are read-only

Sume documents the read groups: meta and health (mcp_health, tools_list, tools_schema), account and catalog reads (account_me, balance_get, usage_get, catalog_list, generation_admission_preview), job reads (jobs_list, jobs_get, jobs_status, jobs_result, jobs_events, jobs_wait), asset reads, avatar reads, crawl reads, and the media inspection reads. The paid creates and the write tools carry idempotency_key.

Do not guess names from memory. Call tools_list in a session and keep the ones marked read-only in the safety metadata, then turn that list into patterns.

A config sketch

Start from the connection block in the API key post and add the tool controls. Note that sume_jobs_* would also match sume_jobs_cancel, a write tool, so the deny list handles it.

enabled_tools = ["sume_jobs_*", "sume_catalog_list", "sume_balance_get",
                 "sume_usage_get", "sume_mcp_health", "sume_tools_list"]
disabled_tools = ["sume_jobs_cancel", "sume_*_create", "sume_generate_*"]

[tools.sume_generation_admission_preview]
permission = "ask"

Check it, then loosen it

After editing, ask Vibe to list the tools it sees for sume, then to attempt a paid call and confirm it is refused. A refusal in the client is a stronger guarantee than a request to the model to behave. Because the server itself does not know about your allowlist, an API key used elsewhere is unaffected; only this Vibe profile is restricted.

When you want one paid job, loosen it deliberately: remove the specific tool from disabled_tools, run generation_admission_preview or a dry_run=true call first, then submit with an idempotency_key and a max_spend_usd. Put the rule back afterwards. For the same idea in another client, see the Codex allowlist post.

Why client-side filtering is not the whole answer

A glob list in your own config file protects one profile on one machine. It does not make the key itself read-only, and it does not stop another client that holds the same key from calling a paid tool. If you need a hard read-only guarantee for a person, the stronger arrangement is OAuth with Write left off, because the server then hides mutating and paid tools and answers insufficient_scope to any attempt. Vibe cannot take that route today, so treat the glob list as a seatbelt rather than a wall.

Two details make the seatbelt more reliable. First, prefer an allowlist over a denylist: a new paid tool added to the hosted registry later is blocked by default instead of allowed by default. Second, re-run tools_list after a Sume change you hear about and compare it against your patterns, since the docs say the live registry is the contract and that HTTP API parity should not be assumed.

Finally, keep permission = "ask" on the one read tool that touches spend, generation_admission_preview. It is free to call, but a human glancing at the estimate is the entire point of calling it.

Verifying what the model actually sees

Do not stop at reading the config. Start a session and ask Vibe to list the tools available from the sume server, then compare the list with tools_list from a direct call. Any tool in Vibe's list that is not on your allowlist means a pattern did not match the way you expected, which is worth knowing before it matters. Pay particular attention to names with hyphens or dots, such as kling-motion-control_create, since glob rules may treat separators differently than you assume.

Keep the allowlist in version control with the rest of the project's Vibe settings, and review changes to it as you would a permission change, because that is exactly what it is.