Beyond per-minute rate limits, connector actions have a per-day ceiling. Hitting it returns HTTP 429 with a structured body:
{
"error": "mcp_quota_exceeded",
"action": "people_reveal",
"daily_limit": 2000,
"used_today": 2000,
"requested_units": 50,
"remaining_today": 0,
"reset": "next_calendar_day"
}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