Iggy Docs MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IGGY_DOCS_ROOT | No | Path to an iggy-website checkout (repo root or content/docs directly). When set, files are read fresh from the local checkout on every call. When omitted, the docs tree is discovered via the GitHub API and fetched from raw files, cached for seven days. | |
| IGGY_RUST_ROOT | No | Path to an apache/iggy checkout. Used to index the public API of the SDK and core crates from rustdoc's JSON output. There is no GitHub mode for the Rust API. When omitted, the Rust API corpus is skipped and the guides serve alone. | |
| IGGY_RUST_CRATES | No | Override for the list of crates whose public API is indexed. Default is 'iggy, iggy_common, iggy_binary_protocol'. | iggy, iggy_common, iggy_binary_protocol |
| IGGY_RUST_DOC_JSON | No | Override for the directory where the <crate>.json files are looked for, if they are not under <IGGY_RUST_ROOT>/target/doc. |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_docsA | List every Apache Iggy documentation page, organised by section. The corpus has two halves. 'website' is the hand-written prose from apache/iggy-website, keyed by site path (server/docker). 'rust-api' is the inline Rust doc comments from apache/iggy, keyed under api/ and linked to docs.rs. Pass source to see one half alone; the default lists both. |
| get_docA | Retrieve the full text of one Iggy documentation page. Use list_docs to discover valid keys such as 'server/docker', 'sdk/python/intro' or 'introduction/getting-started'. |
| search_docsA | Search the Apache Iggy documentation for a term or phrase. Searches both halves of the corpus: the hand-written guides on iggy.apache.org and the inline Rust doc comments from apache/iggy, whose results link to docs.rs. Each result says which half it came from, because the guides say how Iggy is meant to be used and the Rust API says what is actually callable, and those can disagree. Set source to 'website' or 'rust-api' to search one half alone. Prefer this over answering Iggy questions from memory: the SDKs and server move quickly and the docs are the current truth. |
| find_examplesA | Find code examples in the Iggy documentation by topic and language. Use this when a user asks for runnable examples, SDK examples, producer or consumer samples, Docker commands, or source material for tutorials. |
| extract_code_snippetsB | Return an inventory of fenced code snippets from the documentation. The result includes the doc key, title, heading, language, line number, source URL, and code. Use this for snippet verification and docs CI design. |
| get_related_docsA | Return documentation pages related to one doc key. Relatedness comes from explicit links, backlinks, shared section, and shared vocabulary. Use this after get_doc when one page may not contain all context needed for a complete answer. |
| explain_doc_mapA | Explain how the Iggy documentation is organised and where to start. This is a guided map, not a keyword search. Use it when a user asks where docs live, what reading path fits a goal, or which documentation areas look thin from the indexed corpus. |
| find_broken_linksA | Find broken links in a local Iggy documentation checkout. Internal docs links are checked against the indexed local corpus and heading anchors. External URLs are counted but skipped unless check_external is true. |
| refresh_docsA | Re-fetch the documentation corpus, bypassing the seven-day cache. When IGGY_DOCS_ROOT points at a local iggy-website checkout this is a no-op, since local files are always read fresh; run git pull there instead. |
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 9 tools
Each tool has a clearly distinct purpose: listing, fetching, searching, finding examples, extracting snippets, getting related docs, explaining structure, checking links, and refreshing. Even search_docs and find_examples are well-separated by their focus on general search versus example discovery.
All tool names follow a consistent verb_noun pattern (list_docs, get_doc, search_docs, find_examples, extract_code_snippets, get_related_docs, explain_doc_map, find_broken_links, refresh_docs). The pattern is predictable and easy to infer.
Nine tools is well-scoped for a documentation server. Each tool covers a distinct aspect of doc navigation, search, extraction, and maintenance without unnecessary redundancy.
The tool surface covers the full lifecycle of documentation access: discover, retrieve, search, extract examples, find related content, understand structure, validate links, and refresh data. No obvious gaps for a read-only docs MCP.