Jan allow-all MCP permissions and smart routing with Sume tools

Leave Jan's Allow All MCP Tool Permissions switch off when Sume has write access. With it on, Jan approves every MCP tool call without a dialog, and a paid generate_video call is an MCP tool call like any other.

Jan's smart tool routing is a separate setting that decides which connected servers get queried each turn. It affects context size, not spending.

What does Allow All MCP Tool Permissions do?

The Jan MCP page describes it plainly: when enabled, all MCP tool calls are automatically approved without showing permission dialogs. Jan has no per-tool allowlist in that description, so the choice is dialog for every call or no dialog at all.

What stops a paid call if you turn it on?

Sume's own gates are the backstop, and they are narrower than people expect. Per tools and gates:

• Under OAuth with mcp:read only, paid and write tools are not visible, and calling them returns insufficient_scope.
• idempotency_key is required on paid calls, but it is dedup, not human approval.
• dry_run=true returns an admission and cost preview without submitting.
• max_spend_usd caps spend only when you provide it.
• There is no mcp:paid scope, so with mcp:write the wallet is the limit.

What is a safe setup?

The simplest safe arrangement is to connect with Read only and keep auto-approve on, because nothing the assistant calls can spend. Reading jobs, assets, the catalog and crawl results is all available.

When you need generation, either sign in with Write and turn auto-approve off so Jan shows each call, or keep auto-approve on and put a rule in your prompt: every paid call must first run with dry_run=true, and must carry max_spend_usd. The prompt rule is advice to the model, not enforcement, so treat the dialog as the real control.

What does smart MCP tool routing change?

Jan's page says that when you have more than a small number of connected servers, smart routing narrows which servers are queried for tools on each turn, reducing context size, and it can use a lightweight model for the routing step. Sume exposes a long tool list, so on a crowded setup routing keeps its tools out of turns that do not need them.

If the assistant seems unaware of a Sume tool, ask it to call tools_list directly or name the Sume server in your message. Routing decides what is offered; it never changes what a tool costs.

How do you check what the assistant actually did?

Read back the job list. jobs_list shows what was submitted in the session, and usage_get and balance_get show the spend side. If an unattended chat ran with auto-approve on, run those three at the end and compare the job count with what you asked for.

Duplicates are the failure to look for. A repeated idempotency_key returns the original job rather than starting a second one, so duplicates mean the assistant used different keys for what was the same request. Ask it to derive the key from the task, for example a short slug plus the scene number.