Cursor Projects subagents and MCP tools: capping Sume spend

When a Cursor coordinator agent delegates work to subagents that all use Sume's MCP tools, each paid call carries its own gates: a required idempotency_key, an optional dry_run, and a max_spend_usd that is enforced only when a call provides it. Nothing in the Sume docs sums those caps across agents, so the cap has to be in each call your instructions describe.

Cursor's side comes from its changelog, read 2026-09-29: on Sep 10 it announced Cursor Projects (beta), where coordinator agents delegate to subagents. The changelog line says nothing about MCP or spend, so the rest is Sume's documented behavior.

What did Cursor Projects add?

The Sep 10 entry describes Cursor Projects (beta) as coordinator agents that delegate to subagents; it also lists subscriptions that monitor Slack channels, scheduled runs and PR tracking. Whether a subagent inherits your MCP servers is a Cursor question; check Cursor's docs.

Which Sume gates apply to each subagent call?

The gates belong to the tool call, so every subagent that reaches a paid tool meets them independently.

How should subagents choose idempotency keys?

Because the key is for dedup, give each unit of work its own stable key, for example one per scene, and reuse it only when a subagent retries that same unit. Two subagents sharing one key would be treated as one request; two retries with different keys would be treated as two.

Paid write access also depends on the session. OAuth mcp:read sessions see only read-only tools, and mutating and paid calls return insufficient_scope; mcp:write or an API key exposes the full hosted set. There is no mcp:paid scope, so spend is wallet and admission, not a separate permission.

How do I bound a batch of paid calls?

Put the cap in the instruction: tell every subagent to pass max_spend_usd and to run dry_run=true first for expensive work; the docs prefer generation_admission_preview or dry_run before bursts. For three or more independent calls of one shape, script_run runs them on the Sume side and is bounded by timeout_seconds, max_calls and max_paid_calls; paid creates inside still need their own idempotency_key. See MCP tools and gates.

What is a safe order of calls for one paid job?

The docs' inspect-before-paying playbook is a good template for a subagent brief. Call tools_schema with the tool name, for example generate_image. Call generation_admission_preview, or the paid tool with dry_run=true, and confirm the estimate, balance and queue behavior. Then submit with a fresh idempotency_key on a session that has mcp:write or an API key, with max_spend_usd when you want a cap.