Beyond per-minute rate limits, some connector actions have a per-day ceiling. On a plan, counts and search rows have none. During the trial and on pay as you go they are counted for the whole account, every key and the connector together (1,000 counts and 1,000 search rows a day through an AI assistant); reveals and export rows are counted per key. Hitting a ceiling returns HTTP 429 with a structured body:
{
"error": "mcp_quota_exceeded",
"action": "preview_rows",
"daily_limit": 1000,
"used_today": 1000,
"requested_units": 10,
"remaining_today": 0,
"reset": "next_calendar_day",
"scope": "account"
}How to read it
- action - quotas are per action, so exhausting reveals does not block counts.
- requested_units - a call asking for 50 rows costs 50 units, not one. This is why batching is cheaper on quota than looping.
- remaining_today - what is left for that action right now.
- reset - the next calendar day. There is nothing to click and nothing to retry into.
A Retry-After header accompanies the response, so a well-behaved client can schedule itself without guessing.
What to do
- Stop the run cleanly and report what is left, rather than retrying into a wall.
- Batch. One export of 1,000 rows is one job; a thousand single reveals is a thousand requests and a thousand units.
- Verify in batches of up to 500 addresses per call.
- If you hit the daily ceiling regularly, the fix is a higher tier, not a smarter retry loop.
Everything already created stays yours. Exports that were billed remain downloadable, and revealed contacts stay revealed, so a quota stop never costs you finished work.
The account endpoint reports your position before you start, which is the polite thing for an agent to check at the top of a long run:
npx argorant whoami