health_check
Check server health, API key status, and cache readiness before querying Japanese stock data. Use after timeouts to distinguish cache-loading delays from permanent failures.
Instructions
Check server health, API key configuration, and cache readiness.
Offloaded to a worker thread (see _health_check_impl): the body can
trigger the slow lazy cache initialization (connect + migrations), and
the official mcp SDK — unlike the standalone fastmcp package this server
used to run on — invokes sync tool bodies directly on the event loop
rather than in a worker thread, so an explicit asyncio.to_thread
offload is required here to keep that work off the loop. Sharing the
SQLite connection with the loop from that thread is what caused #537;
the store's write lock, not this offload, 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 | |||