health_check
Check server health, API key status, and cache readiness before using other tools to confirm the server is ready.
Instructions
Check server health, API key configuration, and cache readiness.
Sync on purpose: FastMCP runs a sync tool body in a worker thread, which keeps this off the event loop — the body can trigger the slow lazy initialization (connect + migrations). Sharing the SQLite connection with the loop from that thread is what caused #537; the store's write lock, not an async signature, is what makes it safe.
Call this at session start to confirm cache.db has finished loading before issuing detect_* or cache_status — the first call after server start may take 10–60 seconds while the cache initialises lazily. After a tool-call timeout, use this to distinguish a transient cache-loading delay from a permanent failure.
Returns server version, API key status, active plan, status
(healthy / degraded), cache_integrity and cache_ready.
status is degraded only when the integrity check reports a failure;
there is no error state, since this call does no I/O that can fail.
cache_integrity (ok / pending / not-checked / failed: /
error: ) is the integrity check's own result. The last two carry a
detail string appended to the prefix, so test them with startswith,
not ==. cache_ready is a boolean shorthand: true only when
cache_integrity is exactly "ok".
In multi-user mode, returns the authenticated user's plan.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||