Meta Muse Zapier connector: how do I limit what an agent can spend?
Zapier's Muse connector brokers app access over Zapier MCP. Spend limits live in each tool you expose. Here is how Sume's scopes, caps and idempotency keys fit.

Limit it at the tool, not at the connector. Zapier says its connector in Meta's Muse agent reaches more than 9,000 apps and 40,000 actions through Zapier MCP, with Zapier managing authentication and credentials. That makes access easy to grant and says nothing about a per-call bill, so any paid tool behind it needs its own ceiling.
What Zapier says it controls
The announcement says agents can discover and run configured tools, that access depends on user permissions, workspace controls and each app's API limits, and that Zapier holds SOC 2 Type II certification. Availability to Meta users depends on authorization and Meta's rollout. It gives no launch date and mentions no spending controls.
Where a spend limit can sit
Zapier's post also says early-access users can describe an automation in plain language and have an MCP-enabled agent build and deploy it to Zapier. That is a reminder that an agent may create standing automations, not only run one-off actions. Review what a new automation can call before it goes live, and check that anything touching a paid API carries its own limit rather than inheriting trust from the person who approved the connector.
| Layer | What it can do | Sume example |
|---|---|---|
| Connector broker (Zapier MCP) | Decide which tools an agent may run and under whose account | Not documented as a spend control |
| OAuth scope | Hide paid tools from a session | Sume's hosted MCP: mcp:read only sees read tools; Write is off by default on the consent page |
| Per-call parameter | Bound one call | max_spend_usd is enforced when you pass it; dry_run previews cost |
| Per-run cap | Bound a whole agent task | generation_spend_cap_usd is required on Agent Completions |
| Retry safety | Stop a loop paying twice | idempotency_key on every paid or write tool call |
A practical pattern
If an agent platform lets you add a remote MCP server by URL, add Sume's https://mcp.sume.com/mcp and approve Read only. The agent can list tools, check balance_get and usage_get, and inspect jobs without being able to spend. Grant Write only when a human wants media generated, and tell the agent to run dry_run first so the cost shows before the money moves.
Zapier's post does not say whether Muse accepts other MCP servers, so treat this as the pattern for platforms that do, not a Muse feature.
One more habit: log the idempotency_key you gave each paid call next to the agent's session, so a second charge for the same intent is easy to spot.
The question to ask any broker
Before you connect a paid API through a broker, ask where the ceiling lives. If the broker enforces nothing about money, the API must. Sume's answer is layered: scope at sign-in, max_spend_usd per call when supplied, and a required cap per Agent Completion. Pair them with usage.billable_amount_usd_micros in the run receipt, which counts generation spend only, so your alerts compare like with like.
Sources
More in Integrations
- provider.only on Sume image requests: why other slugs return 400
Porting an OpenRouter-style image call? On Sume, provider.only and order accept only sume; other slugs return 400 provider_not_available. Field rules.
- Render a Short over MCP: timeline_create, jobs_wait, timeline_get
Three hosted MCP tool calls turn a Timeline document into a vertical Short: create with an idempotency_key, wait on the job, then fetch the result.
- GitHub Actions job that renders a 9:16 clip on Sume as an artifact
A workflow file that replaces a Sora render step: submit to Sume, poll with a deadline, and upload the mp4 as a build artifact. The key stays in a secret.
- stt_create dry_run and max_spend_usd: cap an MCP transcription run
On Sume's hosted MCP, dry_run previews admission and cost without submitting, and max_spend_usd caps a paid stt_create. Add an idempotency_key to every write.
Written by Sume