Why did I get try_again_later?

Some tools can’t answer right now for reasons that have nothing to do with your request: an upstream provider rate-limited us, a pooled session hit a cooldown, or a probe timed out. Rather than return a misleading empty result, those tools say so explicitly.

1
{ "status": "try_again_later", "retry_after_seconds": 60 }

Over REST and MCP this arrives as HTTP 429 with a matching Retry-After header, so well-behaved HTTP clients pick it up automatically.

What it means

It’s a statement about us and our providers, not about your arguments. The two tools that produce it today:

• get_email: the SMTP path was unavailable, or the pooled Google session is in cooldown. Internally these surface as smtp_unavailable and google_cooldown; both are already post-retry, since the verification legs retry inside their own budget before giving up.
• get_coordinates: the geocoder returned 429, or the request timed out.

Crucially, it is not the same as not_found. A not_found means the work happened and there’s nothing to return, so retrying is pure waste. A try_again_later means the work didn’t happen.

What it costs

It costs the tool’s full price, and each retry costs again.

The reason is the metering order: the cost is debited when the call passes the metering gate, which happens before the tool reaches its provider. There’s no automatic refund. So a tight retry loop on a busy provider multiplies your spend without improving your odds.

Full breakdown in How Tokens Work.

How to retry

• Honor retry_after_seconds. It’s a real number from the tool, not a constant: 60 for a provider rate-limit or Google cooldown, 30 for a network timeout.
• Retry once, then move on. If the second attempt also comes back transient, queue the input and come back later rather than looping.
• Never retry in a tight loop. Ten immediate retries cost ten calls and will almost always return the same signal.
• Batch differently instead. If you’re sweeping a list and a few entries return transient, finish the list first and re-run only the stragglers.

$
# One retry, respecting the tool's own backoff
>
resp=$(curl -s -X POST "$API/get_email" -H "$AUTH" -d "$BODY")
>
if [ "$(echo "$resp" | jq -r .status)" = "try_again_later" ]; then
>
  sleep "$(echo "$resp" | jq -r '.retry_after_seconds // 60')"
>
  resp=$(curl -s -X POST "$API/get_email" -H "$AUTH" -d "$BODY")
>
fi

When it means an outage

One try_again_later is normal background noise. A pattern is a signal:

• Every call for one domain, repeatedly: likely that provider’s edge, not a general outage.
• Every get_email call across many domains: the SMTP verification path is degraded. Reads, LinkedIn tools, and signals will still work.
• Every call to a session-backed tool: check list_connected_linkedin_accounts (free). This is more often a stale pooled session than an outage; see LinkedIn Session Expired.

If a whole tool stays transient for more than a few minutes, contact support with the tool name and the exact arguments.