Rate limits & errors

MCP and REST share a single daily request limit per account. Every counted response carries headers so you can track usage, and errors follow a consistent JSON shape.

Daily limits

One counter covers both MCP tool calls and the REST API. It resets at 00:00 UTC.

Pricing always shows the current allowances — it reads them from the live plan, so trust it over this table if the two ever disagree.

Need more? Compare plans.

Two MCP feedback tools are free and never counted: ReportProblem, for a failed or non-credible call, and SuggestToolImprovement, for a concrete improvement to an existing tool the agent actually called. Reporting our defect or limitation should not cost you a request. See Tools overview for what they send.

Requests without a key

The MCP server answers a keyless request only when it is the handshake or a pure-metadata read (initialize, tools/list, …), so a client can list the tool catalogue before signing in. Anything that would actually run a tool returns 401 — attach a key or complete the OAuth sign-in.

That open path carries its own per-IP cap of 60 requests per minute, separate from the daily limits above. Over it you get a 429 with a Retry-After: 60 header and a message pointing at your API keys. Keyless requests resolve no account, so they never touch your daily counter — but they also never get past metadata, so add a key rather than leaning on this path.

The REST API has no keyless path at all: every request needs a key, and one without it is a 401.

Rate-limit headers

Every counted response includes these headers:

When you hit the limit

Over the limit, the MCP server returns a normal tool result whose text explains the limit and links to upgrade — so your agent can relay it in the conversation rather than surfacing an opaque transport error. The REST API instead returns 429 Too Many Requests with the error envelope below.

{ "error": { "code": "rate_limited", "message": "Daily call limit exceeded.", "status": 429 } }

Error format

Every non-2xx REST response uses the same envelope:

{
  "error": {
    "code": "not_found",
    "message": "Stock not found.",
    "status": 404
  }
}

Every tool and endpoint is available on every plan, so you won't see a 403 from the REST API. The MCP server returns 403 only when an OAuth token is missing the required mcp scope — re-run the connector's sign-in to fix it.

Retries & idempotency

Every REST endpoint is a read-only GET, so all REST requests are safe to retry — no request ever changes state.

• On 429, wait for the Retry-After seconds (the daily counter resets at UTC midnight), then retry.
• On a 500, retry a few times with exponential backoff (e.g. 1s, 2s, 4s). Persisting 500s aren't your fault — tell us.
• On a temporary 503, retry after a short delay. A 503 saying the provider is not enabled requires deployment configuration instead.
• Each request counts once against your daily limit — including each page of a paged read. Fetching 10,000 rows at limit=500 is 20 requests, so budget paging against your plan.

Still stuck?

If a request keeps failing or a number looks wrong, email [email protected] or open a ticket — include the request URL (with the key removed) and the response you got.