The anydocs server provides fast, token-efficient local search and access to coding tool documentation (e.g., Claude Code, Cursor, OpenAI Codex) using BM25-ranked SQLite FTS5 indexing — no API key or network required at query time.
search_docs: BM25-ranked keyword search returning short, relevant snippets (~500 tokens per search). Supports filtering by source and handles symbols (AGENTS.md, --flag-name) as well as plain English queries.
read_doc: Retrieve a full documentation page or a specific heading/section. Supports pagination for large pages via the part parameter and returns related pages for navigation.
grep_docs: Run a Python regex search over raw markdown to find exact occurrences of env vars, config keys, flags, or symbols — useful when search_docs misses something or exhaustive matching is needed.
list_sources: List all indexed documentation sets with page counts and freshness information.
list_pages: Browse a source's pages and descriptions, with optional prefix filtering to narrow results.
Additional features:
Runs entirely locally with a small (~7 MB) index.
Scope available sources via the ANYDOCS_SOURCES environment variable to reduce noise.
Extend with new sources by adding YAML config files to the sources/ directory (supports llms-txt, sitemap, llms-full ingest strategies).
Lexical, no fuzzy matching — reports when words are ignored to avoid misleading results.
Provides search and retrieval of OpenAI Codex documentation, enabling agents to find relevant pages and snippets via BM25 search and regex grep.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@anydocs Search Claude Code docs for MCP tool usage"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives coding agents fast search over other tools' documentation — Claude Code, OpenAI Codex, Cursor, opencode, xAI, and whatever else you add.
Docs are ingested in CI, indexed into SQLite FTS5, and published as a release artifact. The server downloads it and serves five tools:
tool | what it does |
| BM25-ranked hits as short snippets — never whole sections |
| one page, or one heading section of it |
| regex over the raw markdown, for exact symbols BM25 splits |
| which doc sets are indexed |
| a source's pages and descriptions |
A search costs ~500 tokens. Returning whole matched sections instead — the obvious way to build this — costs 10k+ for the same question. That is what makes it cheap enough to check every time instead of guessing.
Everything runs locally: no API key, no network at query time, no service to keep alive. The whole index is ~7 MB.
https://github.com/user-attachments/assets/c900ff65-885c-46fe-a7fc-14486391cc00
A real, unscripted Claude Code session: the Codex/Ollama question from the table below, a follow-up that hits a 49KB doc page and asks for the right section instead of guessing, and an answer that ends on a cited source line - not memory.
Related MCP server: callimachus
Ten questions about config surface that has changed recently — Codex's hooks, Cursor's model access control, Claude Code's permission modes, opencode's agent directory — with ground truth read off the current docs. Each run is a real Claude Code, with WebFetch and WebSearch enabled in every arm: the control is not a model with its hands tied, it is what you already have. Answers graded blind against the key, three independent passes.
wrong answers | accuracy | wall | answered from memory | |
Claude Code alone | 46% | 0.48 | 53s | 10/40 |
+ anydocs | 22% | 0.68 | 34s | 2/40 |
+ anydocs + the | 8% | 0.81 | 30s | 0/40 |
Five times fewer wrong answers - and it is faster at the same time. Reproduce
it with uv run python scripts/eval_agent.py --reps 4 --passes 3 (40 runs per arm).
The middle row is the point. Mounting the server is not enough. With anydocs
available but nothing telling the agent to use it, it sometimes just answers from
memory, and when it does it is wrong in the way that costs you an afternoon. Asked
how to run Codex against Ollama, half those runs replied in a single turn with a
tidy, plausible, superseded config block: model_provider and a
[model_providers.*] table. The current answer is the --oss flag with
oss_provider. One line of instruction takes that to zero, and it is the
difference between 22% wrong and 8%.
That question is also the sharpest thing in the set: without anydocs the agent gets it wrong every single time, even after spending 50 seconds searching the web. With the line, it gets it right every time in about 30.
So the line is not optional. It is in both install paths below. And it cannot be moved inside the server: writing the same instruction into the MCP server's own instructions was measured, and it lands exactly on the middle row.
Codex reads MCP servers from ~/.codex/config.toml or, for a trusted project,
.codex/config.toml. Add it globally with the CLI:
codex mcp add anydocs -- \
uvx --from git+https://github.com/kiyeonjeon21/anydocs anydocs
codex mcp listOr use project configuration. The longer startup timeout covers the first cold
uvx install and index download; required makes a broken server fail loudly.
[mcp_servers.anydocs]
command = "uvx"
args = [
"--from",
"git+https://github.com/kiyeonjeon21/anydocs",
"anydocs",
]
startup_timeout_sec = 120
required = true
[mcp_servers.anydocs.env]
ANYDOCS_SOURCES = "codex"Restart Codex after changing configuration. Then do step 2.
.mcp.jsonFor clients that support .mcp.json, use the following. Nothing needs to be
installed first: uvx fetches the server, and the server fetches the index on
first run.
{
"mcpServers": {
"anydocs": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/kiyeonjeon21/anydocs",
"anydocs"
]
}
}
}Then do step 2.
Put this in the project's AGENTS.md (or CLAUDE.md):
When anydocs MCP is available, use search_docs with the product's source and
then read_doc before answering questions about that product's documentation.Do not skip this. A mounted MCP server the agent does not call is worth nothing, and an agent that feels sure will answer from memory instead — which is exactly when it is wrong. Measured over 160 runs, this line takes the answer-from-memory rate to zero, cuts wrong answers from 22% to 8%, and makes the agent faster (30s against 34s), because one search beats three guesses at a docs URL.
ANYDOCS_SOURCES limits the server to the sources you name. The rest disappear —
from list_sources, from the source enum the model sees, and from every tool,
including direct read_doc calls.
Worth doing. These doc sets describe the same ideas in different words, so on a
Claude Code repo an unfiltered search for hook events hands 3 of its 5 slots to
Cursor and xAI.
{
"mcpServers": {
"anydocs": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/kiyeonjeon21/anydocs",
"anydocs"
],
"env": {
"ANYDOCS_SOURCES": "claude-code,codex"
}
}
}
}In Codex config, the equivalent is:
[mcp_servers.anydocs.env]
ANYDOCS_SOURCES = "claude-code,codex"Available: claude-code, codex, cursor, opencode, xai. A name that is not
in the index stops the server and prints the valid ones, rather than quietly
serving an empty index.
Matching is lexical, and the tools say so rather than bluffing:
English only. The docs are English and matching is by word, so a Korean or
Japanese query reaches nothing. search_docs names the words it had to ignore
instead of quietly answering a question you did not ask.
No fuzzy matching. A typo finds nothing. It is reported as a typo.
OR matching always finds something. Ask Claude Code's docs about
cursorrules and the hits will be pages that merely contain tab. The reply
says which of your words never reached the results, so a weak match cannot pass
as an answer.
Embeddings were measured and left out: dense retrieval alone scored worse than BM25 on these corpora (hit@1 0.775 vs 0.804), and a hybrid moved recall@8 from 0.946 to 0.964 — five questions out of 276 — in exchange for a 130 MB model on every client or a server to keep running. Not worth it yet.
Drop a YAML file in sources/. Sites do not agree on how to publish docs, so
there are three ingest strategies:
strategy | when | example |
| llms.txt is an index of pages, each with a | Claude Code, Codex |
| no llms.txt — take the page list from sitemap.xml | Cursor, opencode |
| llms.txt is the corpus, split by a delimiter | xAI |
id: cursor
title: Cursor
tags: [coding-agent]
strategy: sitemap
entry: https://cursor.com/docs/sitemap.xml
base_url: https://cursor.com/docs/
page_suffix: .md
include: ["https://cursor.com/docs/*"] # the sitemap carries 13 locales
expect_pages: 165 # guards against the site movingTwo things to get right, both of which fail silently:
Locales. Every sitemap carries them, and they can multiply a source by 17.
expect_pages is checked in both directions, so a filter that stops matching
is a build failure rather than a quietly bloated index.
slug_style. Sites slug their heading anchors differently, and a wrong
slug still ranks fine — it just lands in the wrong place, which nothing else
would catch. collapse for Mintlify (CLAUDE.md → claude-md), github for
Astro Starlight (Avante.nvim → avantenvim), verbatim for the rest. CI
checks every anchor against the live HTML on each sync.
CI re-ingests daily and publishes a new index only when the docs actually changed.
uv run anydocs-build # ingest + index into build/
uv run pytest -q
uv run python scripts/eval_search.py # retrieval quality against a gold set
uv run python scripts/verify_anchors.py # anchors resolve on the live sites
uv run python scripts/sweep_chunk.py # re-chunk from pages.body, no refetchA local build/ directory takes precedence over the published index, so
anydocs-build then anydocs serves what you just built.
Retrieval changes need evidence, and every ruler here measures exactly one thing.
scripts/eval_search.py runs three: 15 hand-written questions (precision), 284
auto-derived ones (each page's llms.txt description as the query — broad ranking
movement), and 1,956 built from the anchor text of the docs' own internal links
(recall@8 only, and the only text in the corpus that leaks into neither the index
nor the descriptions). eval_rescue.py and eval_served.py cost model calls and
stay out of CI.
Several plausible improvements died on these numbers, and a few shipped and had to
be reverted because the ruler was wrong rather than the code. AGENTS.md keeps the
list, with the numbers, so nobody spends a day re-deriving them.
Ten questions, chosen by me, all on config surface — the ground a docs tool is supposed to own. It says nothing about a question with no documented answer, and a model that already knows React does not need this. Answers were graded by an LLM against a hand-verified key; a single grading pass moves the accuracy figure by up to 10 points, which is why the table reports the mean of three and the wrong-answer ranges (42-50% / 20-25% / 5-12%) do not overlap where it matters.
Read it as a comparison between the rows, not as an absolute pass rate: the questions were picked to be ones a stale answer gets wrong. An earlier version of this table reported 26 / 20 / 6 from a grader that no longer exists; these numbers come from the checked-in script, whose grading path turned out never to have run end to end. Trust only what you can re-run.
The sample size is load-bearing, not decoration. A variant tested at 20 runs per
arm looked like it matched the AGENTS.md line; at 40 it was no better than not
having it. Halve the runs and this table will happily tell you something false.
MIT
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: AGENTS.md, PreToolUse and
--flag-name all match in search_docs. Come here only when search_docs
missed, or when you need every occurrence of a literal — an env var, a
config key, a flag — rather than the best passages about it.
pattern is a Python regex. Pass source unless you truly want all of them.
Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok).
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | One of: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok) | |
| pattern | Yes | ||
| ignore_case | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety hints. Description adds behavioral traits: returns raw matching lines, costs more (~1.5k tokens for common term), no ranking, hits cap, and clarifies symbols are not a reason to use it. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is about 120 words, well-structured with bold emphasis and clear sections. Every sentence adds value: purpose, when to use, cost caveat, when not to use, parameter hint, source list. Front-loaded with key message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (3 parameters, output schema exists, annotations cover safety), the description covers purpose, usage, behavior, and parameter semantics adequately. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only 'source' described). Description adds that 'pattern' is a Python regex, and advises for 'source': 'Pass `source` unless you truly want all of them.' Also lists indexed sources in description, complementing the enum. Compensates well for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it does 'Regex search over the raw documentation markdown.' It distinguishes from sibling 'search_docs' by explaining it returns raw matching lines, costs more, and is a last resort. Specific verb and resource with differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use search_docs first.' 'Come here only when search_docs missed, or when you need *every* occurrence of a literal.' It tells when not to use (for symbols, as search_docs works) and gives examples of appropriate use cases (env var, config key, flag).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 prefix (one
of the ones it names) to narrow it and get the descriptions back.
Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok).
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | ||
| source | Yes | One of: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. The description adds valuable behavioral context: it is cheap, behavior changes with source size (descriptions vs paths only), and explains the cost reason. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, detailed behavior explanation, param usage, and source enumeration. Every sentence adds value, though it could be slightly tighter without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description provides sufficient context about return modes (small vs large). It covers both parameters and lists sources. Sibling tools are separate, but the tool's purpose is complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but the description adds meaning to the undocumented prefix parameter: 'Pass prefix to narrow it and get the descriptions back.' It also lists its values. For source, it repeats the enum but adds context. This compensates well for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List a source's pages', specifying both verb and resource. It distinguishes from siblings like list_sources (different resource) and search/read tools, and adds behavior details (cheap map) that separate it from more expensive operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('cheap map of what exists') and describes behavior for small vs large sources, implying it's for quick overviews. It does not explicitly mention when not to use it or compare with siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the documentation sets in the index, with page counts and freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only and idempotent. Description adds useful context about the output (page counts and freshness) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 14 words, conveys essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, clear annotations, and existence of output schema, the description fully covers what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Baseline of 4 applies as description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists documentation sets with page counts and freshness, distinguishing from siblings like grep_docs and read_doc which operate on content rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: when one needs an overview of available documentation sets. No explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a documentation page, or one section of it.
path is what search_docs returns, e.g. "claude-code/en/hooks". Pass
section (a heading or its anchor, at any depth) to read just that part —
required for very large pages, which otherwise return an outline to choose
from.
A section that is one huge table — en/settings § Available settings,
en/env-vars § Variables — has no subheadings to outline, so it comes back
in parts, each carrying the table's header row. The reply names the part
count; pass part=2, part=3… for the rest, or use grep_docs to pull a
single entry out of it.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | ||
| path | Yes | ||
| source | No | One of: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok) | |
| section | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds behavior: large pages return outline, tables come in parts with header row, part parameter for pagination, and Related pages footer. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured into paragraphs, front-loaded with core action. Each sentence adds value: section, part, table handling, cross-references. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema (not shown) so return format likely covered. Description addresses purpose, param usage, edge cases (large pages, tables), cross-references, and sources. Complete given complexity and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%). Description explains path (from search_docs), section (heading or anchor), part (for large tables), source (listed). Also explains default behavior (outline if no section). Adds essential meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Read' and resource 'documentation page or one section of it'. Distinguishes from siblings like search_docs (returns paths) and grep_docs. Explains optional section and part for large pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: when to use section (large pages), how to handle huge tables (part), and following cross-references. Lists indexed sources. Could explicitly say when not to use, but implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 source whenever the question names one product. These doc sets
cover the same ground in different words, so an unfiltered search spends
slots on the wrong products: a question about Claude Code hooks will also
return Cursor's and Codex's. Omit source only to compare products, or when
you genuinely do not know which one holds the answer.
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. limit which model an org member can select returns org roles and spend
limits and warns about nothing; model access control — the docs' own name for
it — returns the right page first. You can usually produce that name; the cost
of trying is one more search.
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 — AGENTS.md, PreToolUse, --flag-name, spec_version all
match, because punctuation is treated as a word boundary rather than
dropped. Do not reach for grep_docs just because the query contains one.
There is no fuzzy matching, so a typo finds nothing.
Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| source | No | One of: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description discloses key behaviors: returns ranked snippets, matching is OR, no fuzzy matching, tokens cost ~500, symbols treated as word boundary, and that a note may indicate a word missed. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured and front-loaded with purpose and return type. Every section earns its place (usage, behavior, query strategy, sources). Could be slightly more concise, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of output schema, the description is highly complete: covers usage flow, query formulation, handling misses, token costs, source filtering, and cross-references sibling tools. Leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema description coverage (33%), the description adds rich meaning: explains query format (English keywords, filler words dropped), limit range (1-8), and source usage (filter by product, omit only to compare or when unsure). Provides context not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches documentation and returns ranked snippets (not full pages), clearly distinguishing it from sibling tools like read_doc and grep_docs. It explicitly contrasts with grep_docs, saying not to use grep_docs just because the query contains a symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool first (for documented tools) and when to follow up with read_doc. Gives detailed advice on when to pass source vs omit, and strategies for re-querying when initial results don't cohere. Also notes token cost and recommends budgeting for two searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0grep_docslist_pageslist_sourcesread_docsearch_docsAll 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Token-efficient search for coding agents over public and private documentation.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Shared memory for coding agents. Stop re-explaining your codebase every session.
Versioned documentation registry and semantic search for AI tools and coding assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kiyeonjeon21/anydocs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
