ichi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ICHI_TIMEOUT | No | HTTP timeout in seconds | 10 |
| ICHI_BASE_URL | No | API base URL (testing only) | https://ichi.global |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_indexA | Get the current ICHI score (0-100), band (NORMAL/GUARDED/ELEVATED/HIGH/CRITICAL), per-dimension sub-scores with human-readable names, and freshness/impairment info. ICHI is an outside-in, internet-wide directional signal - not an organization-specific risk score or a forecast. |
| get_recent_alertsB | Get the latest items (default 5, max 50) from ICHI's critical-advisory RSS feed (https://ichi.global/api/alerts): title, link, published time, category, description. |
| get_source_healthA | Summarize ICHI's source health (https://ichi.global/api/health): overall status, confidence, live/stale/failed feed counts, and which sources feed the score. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool maps to a clearly separable concern: the current index/score, the advisory alert feed, and source health diagnostics. An agent can decide between them unambiguously from the names alone, and the descriptions reinforce the boundaries (score vs. alerts vs. upstream feeds).
All three tools follow the same get_<noun> pattern (get_current_index, get_recent_alerts, get_source_health), with snake_case throughout and noun phrases that read naturally together.
Three tools is thin but proportionate for a read-only wrapper over a small public API surface; each tool corresponds to a distinct endpoint and none feels redundant. It could arguably use one more tool (e.g. history), but the scope is tight rather than padded.
The read path for the live signal is well covered (value, alerts, feed health), but there is no way to retrieve historical scores or trends, which is a notable gap for something described as a 'directional signal'. Alert retrieval also lacks filtering by category or time beyond a simple count, leaving some agent workflows to work around the surface.