Reference
Source health
Every source is probed on a schedule, the result is recorded with its latency, and a change of state is announced once. The overview covers why.
The probe
For an MCP server it opens the connection, lists the tools, and asserts that every tool and argument name the source is configured to use exists on the far end. A server that is down, that has withdrawn its authorization, or that has renamed a tool you depend on all fail here.
For a SQL source it opens a read-only transaction and runs the configured list query.
It is deliberately cheaper than the Re-check button, which also lists a record and reads that same record back to prove the reference it asked for is the one it got. Running that daily against every source would spend your upstream rate limit to learn what the probe already answers, so the deeper check stays where a person asked for it.
The states
The last probe succeeded.
The last probe failed. Recorded on the first failure, so the dashboard tells you before anybody is emailed.
A refresh was attempted and refused. This needs a person, so the Reconnect button appears and the notice goes out immediately.
Nothing has checked it yet. Not the same as healthy, and a deployment running no scheduler stays here permanently, which is what it should look like.
What sends mail, and what does not
Owners and admins are told, once per state change. The de-duplication key is stored on the source row, so a daily sweep cannot repeat itself.
| Condition | |
|---|---|
| Two consecutive failed probes | Yes, once |
| A refresh refused: the authorization is dead | Yes, immediately, once |
| A source that was announced starts answering again | Yes, one line |
| An authorization with no refresh token, expiring within 7 days | Yes, once |
| A client registration with an end date within 14 days | Yes, once |
| An access token backed by a refresh token | No. It renews itself |
| A bearer token whose lifetime we were never told | No. We would be guessing |
| A single failed probe | No. The dashboard says so instead |
A notice carries the source name, what the connector reported, and a link. It never carries a memory object, a record or a credential.
Under a partner agreement
A workspace you provisioned through the organization API is never emailed. Its notice reaches your configured callback, HMAC-signed, carrying the source id, its name and its state. The connector's error text is not included: it describes your client's own system.
The same fields are on GET /api/v1/org/tenants/:id/sources, so you can render it yourself under your own name.
On the machine surface
sources_list and GET /api/v1/sources report health, last_checked_at, last_healthy_at, consecutive_failures and credential_expires_at. All of them may be null, which means no probe has run rather than nothing being wrong.
Scheduling it yourself
The sweep is an ordinary route. It refuses outright when CRON_SECRET is unset, because an open one would let anybody make your deployment reach out to every address you have configured.
curl -H "Authorization: Bearer $CRON_SECRET" \ "https://www.contextely.com/api/cron/mcp-health?limit=50"
It takes the oldest-checked sources first, so a run that does not finish is continued by the next one with nothing to reconcile. limit is clamped to 200.