Gemini CLI trust: true on a Sume MCP server: what it skips

Leave trust off for the Sume server unless the session is read-only. Gemini CLI's page says "trust": true bypasses all tool confirmation dialogs, and Sume's docs say idempotency_key is transport dedup, not human approval.

Sources: the Gemini CLI MCP page and Sume's MCP tools and gates, read 2026-09-30.

What does trust: true change?

The Gemini page says "trust": true bypasses all tool confirmation dialogs. That applies to the whole server entry, so read and paid Sume tools alike run without that prompt.

Which Sume gates still apply?

What is a safer setup?

Sign in with OAuth and leave Write off on the consent page, so the session cannot spend. If you need paid tools, keep trust off, or trust the server but use Gemini's includeTools allowlist, which the page says creates an allowlist, to name only read tools. The page also says exclusions take precedence over inclusions.

{
  "mcpServers": {
    "sume": {
      "httpUrl": "https://mcp.sume.com/mcp",
      "trust": true,
      "includeTools": [
        "tools_list",
        "catalog_list",
        "jobs_status",
        "jobs_wait",
        "jobs_result"
      ]
    }
  }
}

Can I add a spend cap to a trusted session?

Yes, per call: the docs say optional max_spend_usd is enforced when provided, and Playbook B suggests dry_run or generation_admission_preview before a paid submit. Those depend on the agent passing them, so the allowlist is the stronger control.

Which Sume tools are safe to trust?

The read tools: tools_list, tools_schema, mcp_health, account_me, catalog_list, the jobs_* reads, assets_list and the crawl_* reads such as crawl_scrape. Those work with mcp:read. The write and paid tools are the ones to keep behind a confirmation dialog, so keep them out of a trusted server entry or out of includeTools, and consider a second, untrusted entry for them.