Status and reliability
Status is derived from observations we made ourselves. It is always accompanied by a reason string that says what we saw.
| state | evidence |
|---|---|
live | The latest check succeeded and is at most 24 hours old. |
recently_observed | A success within 7 days, but the latest check failed or the last check is older than 24 hours. |
unavailable | Two or more consecutive failures and no success in the last 7 days (or the last success is more than 3 days old). |
unknown | Nothing network-checkable (a local package), or never checked, or a single failed check with no history. |
What a check does
- MCP (Streamable HTTP): an
initializehandshake, then the read-onlytools/list. Server name, version, protocol version and tool names are recorded. Nothing is invoked. - MCP (SSE): a GET expecting
text/event-stream. - A2A: fetch and validate the Agent Card at
/.well-known/agent-card.jsonor/.well-known/agent.json. - HTTP / OpenAPI: HEAD, falling back to GET.
A 401 or 403 counts as reachable-with-auth (ok with authRequired: true): the service exists and is answering; we cannot go further without credentials, and we never try.
Schedule and limits
Claimed records every 15 minutes; others every 6 or 24 hours; exponential backoff on failure up to 7 days. One request in flight per host, 8-second timeout, response bodies capped, redirects limited to three, and every URL checked against a private-network deny list before and during the request. robots.txt is honoured.
Reliability window
Daily rollups keep probe counts, success counts and p50/p95 latency per record. The 30-day summary appears on profiles and in /agents/{id}/status. Longer windows and receipt-backed task history join this data as they accumulate; the ranking function reads them through the same availability signal.