compendio-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| docs_overviewA | Map of the documentation corpus: counts by type and module, plus one line per document ([type] path — summary (status)). Use it to enumerate what exists, or to pick filter values for search_docs. When a user names a .md file but its exact indexed path is uncertain, use this to find that path before calling read_doc. For a specific question, call search_docs first — it answers in one call, while orienting here lists the whole corpus before you can read anything. |
| search_docsA | Hybrid search (lexical BM25 + semantic) in natural language over the project's documentation, with metadata filters. Entry point for any question about what the project does or why — behaviour, business rules, the exact text of a user-facing message, limits, endpoints, deployment steps, or the reasoning behind a decision. For a content or project question, this is the cheapest first probe; a filename alone does not reliably identify an indexed path, so resolve named .md files with docs_overview before calling read_doc. Source code remains the authority on current behaviour, while these docs are the only record of intent. The top result carries a full-length excerpt, centred on the part of the document that matched, which usually answers outright; the rest carry short ones, centred on their own match, enough to tell whether the top result is the right one. Each result has path, title, section, excerpt and score; section names the document region the fragment came from — a document with no headings reports one region for the whole file. A '…' at either end of an excerpt marks content omitted there — that is the signal to call read_doc with its path and section. If the project declares convention.excludedStatuses, documents in those statuses are left out unless include_excluded is set; if it declares none, no document is excluded by status. |
| read_docA | Reads one section of a document, along with its frontmatter. Built for sections, not whole files: pass section whenever you can. Omitting it returns the entire document when it is small or cannot usefully be split into sections; a large document with sections returns its outline instead (H2 and H3 headings, each with an estimated token size), so call again with one of those headings as section. To read or summarize a whole document, start from its outline and request the sections you need. When a user names a section in a .md document, pass that named section here after locating the indexed path with docs_overview if necessary. If the path does not exist, it responds with the 3 closest matching paths instead of failing. |
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 has a distinct role: search_docs for finding relevant content, docs_overview for enumerating the corpus, and read_doc for retrieving specific sections. The descriptions explicitly cross-reference when to use one over the other, leaving no real ambiguity.
read_doc and search_docs follow a clear verb_noun pattern, while docs_overview is a noun-phrase exception. All names are lowercase snake_case, so the set is still readable and mostly predictable.
Three tools is an ideal size for a documentation-corpus server: enumerate, search, and read cover the full exploration workflow without redundancy. Every tool earns its place.
The read-side lifecycle is fully covered: search to locate, overview to enumerate, and read to retrieve content. There are no obvious gaps for a read-only documentation server.