Rate limiting

Rate limiting protects your project (and the platform) from runaway tool-call traffic — accidental or otherwise. Three layers apply today: a per-tool, per-caller limit checked during Data Tool execution setup, a per-client ceiling on authenticated MCP requests, and limits on anonymous traffic to public MCP projects, counted per session, per address, and per project. Production MCP calls that reuse cached execution setup bypass the first layer, as described below.

Default limits

Scope	Limit	Where it applies
Data Tool execution per tool, per caller, per minute	300 calls	Requests to the Data Tool execute and preflight endpoints, across production and draft. Production MCP preflight-cache hits do not count. Counted separately for each tool and each caller (API key, user, or OAuth token). Anonymous calls to a public project share one counter per tool.
Authenticated MCP requests per client, per hour	5,000 requests, burst 500	Every request to a project’s MCP endpoint that authenticates with an API key or OAuth token, including `tools/list`. Counted per OAuth client, or per IP address for API-key requests.
Public anonymous tool calls per session, per hour	60 calls (default), burst 10	Public-visibility MCP projects only. Counts tool calls and other requests that do work. Each MCP session has its own allowance; callers without a session share one per address. Authenticated requests (API key or OAuth token) are not subject to this limit.
Public anonymous requests per address	Half the project limit	Every anonymous request from one network address, including opening a session and listing tools. No single address can use more than half of a project’s anonymous capacity.
Public anonymous requests per project	10 × the per-session limit (600 / hour, burst 100 by default)	Every anonymous request to the project, from all callers together. Capped at 6,000 / hour, burst 600.
Public anonymous limits — configurable max	up to 600 / hour, burst 60 per session	Per-project override. Set `settings.mcp.publicRateLimit.requestsPerHour` and `.burst`; the address and project limits scale with them. The platform refuses values higher than the published max to keep “public” from meaning “uncapped.”

Limits apply at the host edge. Once you’re rate-limited, additional calls return 429 Too Many Requests until the window rolls over. Rejected requests stop before they reach a tool, so they don’t appear in the project’s execution history.

The 300/minute Data Tool limit is not a ceiling on every handler invocation. Production MCP execution can reuse a cached preflight bundle (30-second default lifetime), skipping the preflight request where this counter is enforced. Each cache hit still runs the handler but does not consume the Data Tool minute budget. The separate MCP request limits still apply. Draft executions bypass this cache.

What gets rate-limited

The Data Tool minute cap applies when a call reaches an execute or preflight endpoint:

Model-initiated calls from MCP hosts (Claude, ChatGPT, and any custom host), except production preflight-cache hits.
Calls from the Assistant SDK in your iOS, Android, or React app, with the same exception when routed through production MCP.
Test-panel runs in Metabind Studio (yes, even your own testing).
Programmatic calls via the REST API.

What doesn’t count toward the Data Tool minute cap:

Production MCP executions that reuse a cached preflight bundle — these still count toward the applicable MCP request limit.
tools/list calls — these count toward the MCP request limits instead (per client, or per address and per project for anonymous public traffic).
Interactive Tool renders — the tool-execution rate limiter is scoped to the Data Tool sandbox.
Metabind Studio editor operations.
Execution history and analytics queries.

The anonymous limits apply only to unauthenticated traffic against public-visibility MCP projects. As soon as a request authenticates with an API key or OAuth token, they’re not consulted. Opening a session, listing tools, and loading a view count toward the address and project limits only, so they don’t use up a session’s tool calls.

Per-project public rate-limit configuration

For a public-visibility project, override the default via the API:

{
  "settings": {
    "mcp": {
      "visibility": "public",
      "publicRateLimit": {
        "requestsPerHour": 300,
        "burst": 30
      }
    }
  }
}

The platform rejects requestsPerHour values outside [1, 600] and burst values outside [1, 60]. Higher values require a support conversation — the published max is enforced in code, not policy. For private projects, the anonymous limits are irrelevant — every request is authenticated.

Authenticated traffic

Authenticated MCP requests are limited per client to 5,000 per hour, with a burst of 500. Authenticated traffic is also bounded by:

The Data Tool minute cap (300/min per tool and caller) when execution reaches an execute or preflight endpoint; production MCP preflight-cache hits bypass this cap.
Underlying infrastructure protections (timeouts, sandbox concurrency, AWS-side throttling).

If you’re planning a high-throughput deployment that you expect to exceed the Data Tool 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 Retry-After header. The MCP endpoint returns a JSON-RPC error:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32004,
    "message": "Rate limit exceeded",
    "data": { "retryAfter": 12, "scope": "client" }
  },
  "id": null
}

On anonymous traffic, data.scope names the limit that refused the request: client (the session), address, or project. The Data Tool execute endpoint returns:

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Data tool execution rate limit exceeded. Try again later."
  }
}

Over MCP, the AI receives this message as a tool result with isError: true. Retry-After (and data.retryAfter) is the wait time in seconds until the bucket has capacity again. Hosts and clients should respect it — retrying immediately just spins on the rejection.

What the model sees on rate limit

Over MCP, a rate-limited call comes back as a structured error with a retry delay. What happens next is up to the host and its model: some retry after the delay, and some tell the user the tool is unavailable. In a custom host, implement retry with backoff yourself, and respect Retry-After.

Long-running operations

When an execution is counted, a Data Tool that runs near the 60-second sandbox limit consumes one call’s budget. 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, split the work so a slow call doesn’t turn into repeated retries that burn the rate budget. See Sandboxed execution.

Client-side throttling

Even with server-side limits, throttle on the client for hosts you control:

Assistant SDK. The SDK surfaces a 429 as an error rather than queuing the call, so retry after Retry-After in your app if you need to.
Custom MCP clients. Use a token bucket of 300/minute per tool and caller to bound executions even when production preflight-cache hits bypass the server’s Data Tool counter. Also respect the separate MCP request limits.
Batch when possible. A Data Tool that takes a list of IDs uses one execution; one call per ID uses N.

Monitoring

Rate-limit rejections aren’t recorded in the project’s execution history, so watch for them where the calls are made: count 429 responses, and read data.scope to see which limit refused them. Key signals:

A spike of 429s against one project. Either traffic outgrew the Data Tool 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. scope: "address" points to one network address; scope: "project" means all anonymous callers together hit the ceiling.
Sustained 429s. Plan capacity with support; the Data Tool cap is the limit you’ll need to discuss raising.

Custom MCP hosts

Rate-limit headers and errors from a client’s side.

Project visibility

Public projects, the kill-switch, and anonymous access.

Sandboxed execution

Concurrency and time limits inside the sandbox.

Schema validation

Server-side gates on tool calls.

Getting Started

Core Concepts

Building Your MCP App

Publishing

Connecting to MCP Hosts

Assistant SDK

Operations

Sample Apps

Default limits

What gets rate-limited

Per-project public rate-limit configuration

Authenticated traffic

Rate-limit responses

What the model sees on rate limit

Long-running operations

Client-side throttling

Monitoring

Custom MCP hosts

Project visibility

Sandboxed execution

Schema validation

​Default limits

​What gets rate-limited

​Per-project public rate-limit configuration

​Authenticated traffic

​Rate-limit responses

​What the model sees on rate limit

​Long-running operations

​Client-side throttling

​Monitoring

​Related

Custom MCP hosts

Project visibility

Sandboxed execution

Schema validation

Default limits

What gets rate-limited

Per-project public rate-limit configuration

Authenticated traffic

Rate-limit responses

What the model sees on rate limit

Long-running operations

Client-side throttling

Monitoring

Related