Anahita MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANAHITA_SITE | No | The website the two documentation files (docs index and API reference) are read from, e.g. a local build of anahita.io | https://www.anahita.io |
| ANAHITA_MCP_CACHE | No | The folder in which the fetched copies of the docs and API files are kept | your system's cache folder (e.g. ~/Library/Caches/anahita-mcp on macOS, ~/.cache/anahita-mcp on Linux, %LOCALAPPDATA%\anahita-mcp\Cache on Windows) |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_docsA | Searches Anahita's docs by words and gives the best sections first, each with the page and section to read and a line of it. |
| list_docsA | Lists every page of Anahita's docs, in its groups, with each page's name for read_doc and its sections. |
| read_docA | Reads one page of the docs as Markdown, or one section of it with the sections under it. |
| list_endpointsA | Lists the API's services in their groups; with a service, its routes; with words, the routes that match them. |
| read_endpointA | Reads one API route in full: who may call it, its parameters and body, and every answer it gives. |
| read_shapeB | Reads one shape of the API (a schema a route takes or answers with) and its fields. |
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 6 tools
Each tool has a clearly distinct action/resource pairing: browse docs (list_docs), read a page (read_doc), search docs (search_docs), browse API services/routes (list_endpoints), read a route (read_endpoint), read a schema (read_shape). List vs. read vs. search are visibly different operations with no realistic misselection risk.
All names follow a strict verb_noun snake_case pattern (list_*, read_*, search_*), with singular nouns for single-item reads and plural for collections. The convention is predictable and readable throughout.
Six tools is well-scoped for a read-only documentation/API reference server — one tool per content type (docs, endpoints, shapes) each with browse/read/search coverage. Nothing feels padded or missing at the structural level.
The docs surface is complete (list, read, search), but the API surface lacks a dedicated search over routes or shapes and no standalone list_shapes, so shapes are only reachable via read_endpoint. Agents can work around this by browsing list_endpoints, so the gap is minor.