Skip to main content
Rate limiting protects your project (and the platform) from runaway tool-call traffic — accidental or otherwise. Two layers apply today: a per-project ceiling on Data Tool execution, and a per-IP ceiling on anonymous traffic to public MCP projects.

​
Default limits

Limits apply at the host edge. Once you’re rate-limited, additional calls return 429 Too Many Requests until the window rolls over. The audit log captures rejections for diagnosis.

​
What gets rate-limited

The per-project Data Tool minute cap counts every Data Tool execution, regardless of where it came from:
  • AI-initiated calls from MCP hosts (Claude Desktop, ChatGPT, and any custom host).
  • Calls from the Assistant SDK in your iOS, Android, or React app.
  • Test-panel runs in MCP App Studio (yes, even your own testing).
  • Programmatic calls via the REST API.
What doesn’t count toward the Data Tool minute cap:
  • tools/list calls — host capability discovery is uncapped under normal usage.
  • Interactive Tool renders — the tool-execution rate limiter is scoped to the Data Tool sandbox.
  • MCP App Studio editor operations.
  • Audit log queries.
The per-IP public limit applies only to anonymous traffic against public-visibility MCP projects. As soon as a request authenticates with an API key or JWT, the per-IP limit is not consulted.

​
Per-project public rate-limit configuration

For a public-visibility project, override the default in Settings → MCP → Public rate limit or via the API:
The platform clamps requestsPerHour to [1, 600] and burst to [1, 60]. Higher values require a support conversation — the published max is enforced in code, not policy. For private projects, the per-IP public limit is irrelevant — every request is authenticated.

​
Authenticated traffic

There is no documented per-token or per-user rate limit on authenticated calls today. Authenticated traffic is bounded only by:
  • The per-project Data Tool minute cap (60/min) when a tool execution is involved.
  • Underlying infrastructure protections (timeouts, sandbox concurrency, AWS-side throttling).
If you’re planning a high-throughput deployment that you expect to exceed the per-project minute cap, contact support early — capacity-planning conversations with concrete QPS numbers move faster than runtime escalations.

​
Rate-limit responses

When a call is rejected, the response is HTTP 429 with a structured body:
retry_after_seconds is the wait time until the bucket has capacity again. Hosts and clients should respect it — retrying immediately just spins on the rejection.

​
What the AI does on rate limit

Most AIs handle 429 responses gracefully:
  • Anthropic’s Claude pauses and retries after the indicated delay.
  • OpenAI’s GPT models log the error and may surface it to the user if retries fail.
  • Custom hosts: implement retry-with-backoff yourself.
The AI sees a structured error, so it can also explain the situation to the user: “I’m being rate-limited; let me wait a moment and try again.” Whether the user sees this depends on the host’s UX.

​
Long-running operations

A Data Tool that runs near the 60-second sandbox limit consumes one call’s budget while running. It does not keep counting against the minute cap second by second — but it does take an execution slot until it returns. For long-running flows, design with task support so the client polls without burning the rate budget on retries. See Sandboxed execution: task support.

​
Client-side throttling

Even with server-side limits, throttle on the client for hosts you control:
  • Assistant SDK. Already queues over-limit calls rather than failing.
  • Custom MCP clients. Implement a token bucket sized to match the server limit — for the Data Tool cap, that’s 60/minute project-wide.
  • Batch when possible. A Data Tool that takes a list of IDs costs one call; one call per ID costs N.

​
Monitoring

The audit log captures every 429. Key signals:
  • A spike of 429s against one project. Either traffic outgrew the per-project cap, or a misbehaving caller is hammering one tool.
  • Public-anonymous 429s. A public project is hot; either the default is too tight for the use case, or someone’s running a script. Inspect the IP distribution in the audit log before raising.
  • Sustained 429s. Plan capacity with support; the per-project Data Tool cap is the limit you’ll need to discuss raising.

Audit logs

Where rate-limit rejections are recorded.

Project visibility

Public projects, the kill-switch, and the per-IP limit.

Sandboxed execution

Concurrency and time limits inside the sandbox.

Schema validation

Server-side gates on tool calls.