Cline autoApprove for Sume: list only the read-only tools
Cline's remote MCP entry supports an autoApprove array. Put Sume's read tools in it and keep paid creates such as generate_image on manual approval.

Add autoApprove to your Sume entry and list only tools that cannot spend money: mcp_health, tools_list, tools_schema, account_me, balance_get, catalog_list and jobs_list. Leave every create tool off the list so Cline asks before it runs.
Cline's remote server page (read 2026-10-07) documents the streamableHttp type and an autoApprove array. The tool names come from Sume's docs.
The config entry
Cline stores MCP servers as JSON. A remote server uses the streamableHttp type with a URL, and autoApprove holds the names of tools it may run without asking. How you authenticate depends on your Cline version, so follow Cline's page for sign-in or headers and keep keys out of the file.
{
"mcpServers": {
"sume": {
"type": "streamableHttp",
"url": "https://mcp.sume.com/mcp",
"autoApprove": [
"mcp_health",
"tools_list",
"tools_schema",
"account_me",
"balance_get",
"catalog_list",
"jobs_list"
]
}
}
}Why those seven
Each is a read tool in Sume's tools-and-gates docs. mcp_health, tools_list and tools_schema describe the server. account_me and balance_get describe the workspace and wallet. catalog_list lists public capabilities and jobs_list lists work already submitted.
None of them change data or start a paid job, so an automatic approval cannot cost anything.
Tools to keep manual
Paid tools and tools that change data need your eyes. Sume requires an idempotency_key on each of them. That key is for deduplication and is not a person's approval, so approval must come from Cline.
| Tool | Put in autoApprove? |
|---|---|
mcp_health, tools_list, tools_schema | Yes |
account_me, balance_get, catalog_list | Yes |
jobs_list, jobs_get, jobs_result | Yes |
jobs_wait | Yes; it only reads status |
jobs_cancel, assets_create | No |
generate_image, generate_video, tts_create, music_create | No |
Combine it with OAuth read scope
The strongest setup uses both layers. Sign in with Sume OAuth and leave Write off, so paid tools are not even listed. Then autoApprove removes prompts for the read tools. When you need generation, reconnect with Write on, but keep the creates off autoApprove.
Add dry_run to the first paid call each session, and put a max_spend_usd in your instructions.
Sume's tool list can grow. Do not copy a list from a blog post and leave it for a year. Call tools_list now and then, compare it with your autoApprove entries, and add only new tools that the live metadata marks as read-only. A tool you do not recognise stays manual until you have read its schema with tools_schema.
Treat a rename the same way: an entry that names a retired tool does nothing, and a new name is not approved until you add it.
What autoApprove does not protect
It only decides when Cline asks you. It does not cap spend. If you later add a create tool to the list, the agent can run it without a prompt, and the only remaining brakes are the wallet and the arguments you gave. For that reason keep max_spend_usd in every paid call, and do not add generate_video to the list for convenience.
Check it worked
Ask Cline to call balance_get and watch for no prompt. Then ask it to preview one generate_image with dry_run. It should ask first, or, on a read-only session, report that the tool is not available.
Sources
Related posts
More in Integrations
- BigQuery product table to Sume bulk queues and a queue map
Read active SKUs from BigQuery, cast columns to plain JSON types, create one Sume bulk queue per 100 rows, and stream queue id, index and SKU to a map table.
- Copilot 'MCP servers in Copilot' policy: admin checklist for Sume
For Copilot Business and Enterprise, an MCP servers in Copilot policy controls remote servers. What an admin checks before allowing Sume's hosted endpoint.
- Deno.cron weekly Sume video run with a per-day idempotency key
A Deno.cron job that starts one Sume Format run each Monday, keyed by UTC date so a double fire replays, skips overlap, and hands the result to a webhook.
- Forward a finished Sume run to team chat with a signed webhook
A standard-library Python receiver that verifies the sume-v1 signature, rejects an empty secret, and forwards primary_output_url when a Format run ends.
Written by Sume