Two kinds of limit apply to the API and the MCP server. They are easy to confuse because
both say “no” for a while; they are unrelated.
The request limit, per token
Each token may make a fixed number of requests per minute — 120 today, counted in a
window that resets every minute. A request past that answers 429 rate_limited with a
Retry-After header naming the seconds until the window resets, and the same number in
the body as retry_after_seconds:
The counter is per token, not per workspace or per user: two tokens in the same workspace
have two counters. It is also durable, so a refusal survives the application restarting;
waiting is the only thing that clears it.
The MCP server sits behind the same door, so a chatty assistant meets the same limit. A
refused request is not “used”: it does not update the token’s last-used time.
Honour Retry-After rather than retrying on a fixed schedule. Most HTTP clients treat
429 as retryable and will wait the right time if you let them read the header.
Two more 429s
Separately, two abuse bounds answer 429 limit_reached with a sentence naming the bound
that was hit. They are the same on every plan, and neither is something the plan sets:
- 300 new links per day, per workspace. Counted the same way whether the link came
from the console, the assistant or the API. The refusal carries no
Retry-After header.
- 10,000 conversions per hour, per token. The refusal carries a
Retry-After header
and retry_after_seconds in the body, like the request limit.
The MCP server returns the link bound’s sentence as a tool result; there is no conversions
tool. Same status as the request limit, different code: branch on code, not on the
status.
What is not a limit here
The product’s own chat assistant, inside the console, runs under bounds of its own so that
a conversation cannot run away. Those bounds are the chat’s, not the API’s or the MCP
server’s: nothing you build against either door is affected by them, and nothing here
lets you change them. 
