Rate limits for creative MCP workflows
Separate request bursts, daily generation limits, polling behavior, and backoff.
Get practical MCP creation notesTreat an MCP rate limit as a service boundary, not a protocol constant
Do not assume that one number governs every MCP generation workflow. A service may document separate request-burst limits, account generation quotas, active-job ceilings, provider throttles, or storage-layer write limits. Identify the documented or observed boundary before deciding whether to wait, poll, cancel, or ask a person to change the plan. Treat a successful tool-discovery response only as evidence that the tool was visible at that moment; unless the service explicitly documents capacity reservation, do not infer that discovery reserves a later generation call.
For Streamable HTTP in the current 2026-07-28 MCP specification, every request carries `Mcp-Method`; `tools/call` also carries `Mcp-Name`. Those required headers let gateways distinguish a status read from a generation call without parsing the JSON-RPC body, but they do not create a universal quota. Numeric limits and counting scope remain service-specific facts that must come from current documentation or an actual response.
- Burst
- Requests accepted inside a short rolling windowA burst limit can cover reads and writes differently; do not assume every tool call consumes the same budget.
- Daily quota
- Generation starts accepted for an account windowConfirm whether the window is rolling or calendar-based and which attempts count.
- Concurrency
- Jobs allowed to remain active togetherWaiting for an active job to finish is different from waiting for a request-rate window to reset.
Do not confuse a KV write ceiling with the user-facing quota
Cloudflare currently limits Workers KV writes to the same key to one per second on both free and paid plans. Its binding documentation says another write to that key inside one second can throw a `429 Too Many Requests` error. This is an infrastructure constraint. It does not mean that an MCP account is entitled to one generation each second, nor does it define a daily creative allowance.
The distinction matters when a limiter stores one mutable bucket per user or API key. Concurrent requests can contend on that storage key even when the advertised service quota appears to allow both operations. Cloudflare also describes KV as eventually consistent and warns that concurrent writes to one key can overwrite one another. A precise global counter therefore needs an architecture designed for coordination; a reader should not infer exact enforcement behavior merely from the presence of KV.
- Current KV ceiling
- One write per second to the same keyThe limit applies to the storage key, not automatically to a user, tool, model, or generation.
- Collision symptom
- A KV write can fail with 429Record whether the rejection came from storage, the public API gateway, or the generation service.
- Design implication
- Consolidate same-key writes or use coordinated stateDo not market an eventually consistent read-modify-write bucket as an exact global counter without a test.
Read the 429 response before scheduling a retry
HTTP `429 Too Many Requests` means the client sent too many requests in a period chosen by the server. RFC 6585 allows the response to include `Retry-After` and explicitly leaves the counting method open: a service can count per resource, across a server, by authenticated identity, or another policy. Do not convert one observed 429 into a claim about every endpoint or every account.
`Retry-After` has two standard forms: an HTTP date or a non-negative number of seconds after the response. Parse the form actually returned, wait at least that long, and place the retry inside a finite workflow deadline. If the header is absent, use bounded exponential backoff rather than a tight loop; Cloudflare recommends exponential backoff for same-key KV 429 errors. Add a retry cap and surface the unresolved operation to a person instead of allowing an agent to wait forever.
- Header present
- Honor the returned date or delay in secondsUse the response as the minimum wait and keep the workflow's overall deadline.
- Header absent
- Use capped exponential backoffBackoff is a fallback policy, not evidence of the server's reset time.
- Retry exhausted
- Stop and preserve the error contextRecord status, headers, tool name, job identifier if any, and the last attempt time.
Separate submission retries from status polling
Treat creation and status as different operations unless the service documents otherwise. After a timeout or lost response, do not assume either rejection or acceptance and do not automatically repeat the creative request. First check whether any response supplied an operation identifier. Then inspect current service documentation for a status or recent-operation lookup and for an explicit idempotency contract. If none is documented, stop for operator review rather than claiming that a repeated call is safe, billable, durable, or deduplicated.
When the service has returned an accepted operation identifier and documents a status path, poll that identifier with a bounded cadence, honor any server delay, and stop at a declared deadline. The current MCP request headers expose method and tool name to compatible HTTP infrastructure, which makes method-specific policy technically possible. That specification fact does not establish that any particular service assigns generation and status calls different quotas, supports durable jobs, or offers idempotent submission; verify each behavior before tuning an agent.
- Unknown submission
- Do not infer an outcome from a timeoutUse a documented lookup when available; otherwise stop for review rather than assuming a repeat is safe.
- Known job
- Use the returned identifier only with a documented status pathDo not claim durability, billing behavior, or deduplication unless the current service contract states it.
- Bound reached
- Return control to the operatorA finite wait budget prevents a rate-limited workflow from becoming an invisible permanent loop.
Verify the product quota at the point of use
OfflineCreator Studio's current Acceptable Use Policy says automated use through personal API keys, MCP, and the CLI is allowed within published rate limits and makes the account holder responsible for agent requests. That policy itself does not state numeric request or daily-generation thresholds. This page therefore does not publish an OfflineCreator number from private implementation code or assume that a development constant is the production contract.
Before a production run, check current public documentation and the authenticated response surface for the limit, remaining budget, reset guidance, and counting identity. Preserve the full 429 headers without preserving credentials. Recheck after plan, endpoint, or protocol changes. A daily generation quota should shape the creative plan before submission: reserve attempts for approved prompts, avoid duplicate jobs, and stop when the remaining budget cannot cover the agreed shortlist.
- Public fact
- Agent use is subject to published rate limitsThe policy does not provide the numeric thresholds needed for a current quota table.
- Required verification
- Limit, remaining budget, reset, and scopeConfirm whether the counter follows an account, credential, route, tool, model, or another identity.
- Preserved gap
- No authenticated limit test was runNo claim is made about production throughput, enforcement precision, or plan-specific allowances.
Choose the next concept from the failed boundary
Choose the error-design guide when the unresolved task is classifying a rate response separately from authentication, scope, credit, upload, or provider errors. Choose the signed-resource guide when the observed failure concerns an output link's lifetime or access; verify that guide's current sources before deciding whether the service supports refreshing access without creating another generation. Return to the learning center when transport, tools, authorization, and operation lifecycle still need to be separated before setting an automation policy. These links route research questions; they do not establish that a specific job is durable, an output already exists, or a refresh path is available.