anydocs
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANYDOCS_SOURCES | No | Comma-separated list of documentation sources to include. Defaults to all sources. Available: claude-code, codex, cursor, opencode, xai. |
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_sourcesA | List the documentation sets in the index, with page counts and freshness. |
| search_docsA | Search the documentation. Returns ranked snippets, not full pages. Use this first for any question about a documented tool. Follow up with read_doc on the paths it returns. If a NOTE says one of your words missed, believe it. Matching is OR, so a distinctive word can be outvoted by the common ones next to it — the note names the pages that word really lives on. Read one before you conclude the feature does not exist. Pass A search costs ~500 tokens. Budget for two. The first query is the one you
can phrase; the second is the one the docs would. If the rows do not cohere
around your question — they name adjacent features, or only things you already
knew — do not answer from them. Guess what the docs call the thing and search
again. Query in English. The indexed docs are English and matching is lexical, so a question in another language finds nothing — translate it to English keywords first ("훅 이벤트 목록" -> "hook events list"). Keyword-style queries work best and filler words are dropped. Symbols are
fine here — Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok). |
| read_docA | Read a documentation page, or one section of it.
A section that is one huge table — The Related pages footer is the page's own outgoing cross-references — what its authors thought you should read next. Follow them when the question spans more than the one page you happened to land on. Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok). |
| grep_docsA | Regex search over the raw documentation markdown. Use search_docs first. This is the last resort, not the first move. It returns raw matching lines, so it costs several times what a search costs and gives you no ranking — an unscoped grep for a common term burns ~1.5k tokens and still hits its cap. Symbols are NOT a reason to come here:
Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok). |
| list_pagesA | List a source's pages — a cheap map of what exists. Descriptions come with the listing while it is small. A large one is served
as paths only, with the directory prefixes and their page counts, because the
descriptions alone would cost more than fifteen searches. Pass Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok). |
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 5 tools
All five tools have clearly distinct purposes: search_docs for ranked snippet search, grep_docs for raw regex fallback, read_doc for full page/section reading, list_sources for enumerating documentation sets, and list_pages for mapping pages within a source. No overlap in functionality.
Every tool follows a consistent verb_noun pattern with snake_case (e.g., grep_docs, list_pages, search_docs), making the naming predictable and easy for agents to infer tool behavior.
Five tools is an ideal size for a documentation server: it covers all essential operations (listing, searching, reading) without bloat. Each tool earns its place and the set is well-scoped for the domain.
The tool surface is complete for a read-only documentation server. It provides listing, searching (both standard and regex), and reading capabilities. The inclusion of grep_docs as a last-resort raw search fills a niche gap, and no obvious CRUD operations are missing for this use case.