Zapier MCP costs two tasks a call: batch Sume jobs_wait first

Zapier states that each MCP tool call uses two tasks from your task quota. If one agent runs Sume generations and then posts each result through Zapier, call Sume's jobs_wait once with up to 20 job_ids, then make one Zapier call for the whole batch instead of one per item. Sume calls do not consume Zapier tasks, since they go to a different server.

Pattern

Zapier says MCP is included in every plan and draws on the same task bucket as Zaps. Fan-out wastes that bucket, so shape the loop around Sume's batch features.

• Submit the Sume jobs, each with its own idempotency_key.
• Call jobs_wait with job_ids (1 to 20) and wait_for: all.
• If wait_slice_expired appears, repeat the same wait; do not resubmit.
• Read the results with one jobs_result batch call.
• Send one combined message through Zapier.

Arithmetic

Twenty finished images posted one by one cost 20 Zapier calls, which is 40 tasks. Posted as one digest, they cost one call, which is 2 tasks. Sume's side is the same either way: one batch wait and one batch read replace 20 waits and 20 reads.

Caveat

Zapier's page does not say which transport it uses, so check your client's connector for Zapier separately. The Sume side needs only the hosted URL and OAuth or a key.

Checking your own quota

Zapier says its MCP calls draw on the same task bucket as Zaps, so a heavy agent can use up the quota meant for your automations. Look at your plan's task count and divide by two to see how many MCP calls it affords. Then count how many Zapier calls your agent makes per run and see whether batching brings it inside the budget.

Keeping Sume out of the count

The Sume steps are separate. They draw on your Sume wallet and admission limits, not on Zapier tasks. Use a single batch wait and a single batch read, so the agent holds one Sume job set in context and produces one digest for the Zapier step.

Check how failed calls are treated before you design retries. Zapier's page says what counts as a task, and it is worth reading before you build a loop that retries on errors. On the Sume side, a retry of a wait is free of charge, while a retried create needs the same idempotency_key. Keep these two kinds of retry apart in the agent's plan, so an error from one service does not trigger a repeat on the other.

Before you rely on this setup, run a short acceptance test with a read-only credential. Connect, call mcp_health, call tools_list, and read one job with jobs_status. Record the tool count you see, so you can notice later if a credential change alters it. Then repeat the test after any config edit. A five-minute test like this catches most wiring mistakes before they cost money, and it gives you a baseline to compare against when something behaves differently next week.