Fresh, source-verified docs for building MCP servers and Claude agents — served straight to your AI coding agent over MCP.
Coding agents hallucinate on fast-moving APIs like the Model Context Protocol and the Claude Agent SDK: training data lags the spec, so you get plausible-but-wrong imports, deprecated patterns, and invented options. agentdocs is a local MCP server that gives your agent a curated, source-verified corpus to search instead of guessing.
🔎 Three tools: list_topics, search_docs, get_doc
📎 Every answer is attributed to its upstream source URL
🏠 Runs locally over stdio — no account, no hosting, no data leaves your machine
✅ Each doc carries a verified flag set only after human review against the source
Requires Node.js 18+.
claude mcp add agentdocs -- npx -y mcp-agentdocs@latestmcp.json){
"mcpServers": {
"agentdocs": {
"command": "npx",
"args": ["-y", "mcp-agentdocs@latest"]
}
}
}Then ask your agent things like "check agentdocs for how MCP stdio handles logging" or "search agentdocs for the Streamable HTTP session header" — it will call the tools and answer from the verified corpus.
Related MCP server: devdocs-mcp
Tool | Use it to |
| See every curated doc, its topic, source URL, and verified status |
| Get ranked, source-attributed snippets for a question |
| Read the full verified markdown of one document |
The Model Context Protocol (spec 2025-11-25) and building MCP servers / Claude agents.
Corpus grows over time; run list_topics for the current set.
Every document records the date it was last verified against its primary source. Sources
are diffed on a regular cadence; when one drifts, the affected doc is re-verified and a new
version is published. Using mcp-agentdocs@latest (as above) keeps you on the current corpus.
See CHANGELOG.md for what changed and when.
npm install
npm run build # tsc -> dist/
npm test # vitest: retrieval, manifest integrity, unicode safety
npm run ingest # refresh sources into corpus/_staging/ for human reviewCuration is the point: npm run ingest fetches upstream sources for review but never
silently overwrites a curated doc — a human diffs, promotes, and sets verified: true
in corpus/manifest.json only after checking the content against its source. Run
npm run check-freshness to flag docs that have drifted or are due for re-verification.
MIT
Fetch the full curated markdown of one document by its id (from list_topics or search_docs). Use when a snippet is not enough and you need the complete, verified document.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id, e.g. 'mcp-transports'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits like auth requirements, rate limits, or potential errors. It mentions 'verified' but lacks detail on what that entails.
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?
Two concise sentences, front-loaded with the core action followed by usage guidance. No extraneous words.
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?
For a simple one-parameter tool with no output schema, the description covers purpose, source of input, and when to use. Could mention error handling or format assurance.
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 describes 'id' with example; description adds context that the id comes from list_topics or search_docs, adding value beyond the 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 clearly states the verb 'Fetch', the resource 'full curated markdown of one document', and specifies the id source from sibling tools (list_topics or search_docs), distinguishing it well.
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?
Explicitly says when to use: 'when a snippet is not enough and you need the complete, verified document.' Also indicates the id comes from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every curated document available, with its topic, source URL, and last-verified date. Call this first to see what is covered before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes output fields but does not disclose any behavioral traits like pagination, permissions, or rate limits. Adequate for a simple list tool but could be richer.
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?
Two concise sentences, no fluff. First sentence states action and output, second gives usage guidance.
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?
Tool has no parameters, no output schema, and is simple. Description fully covers what it does and when to use it, relative to siblings. Complete for its complexity.
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 in schema (coverage 100%), so description does not need to add param info. Baseline of 4 for zero-param case.
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 'List' and resource 'curated document', with specific fields (topic, source URL, last-verified date). Differentiates from siblings get_doc and search_docs by being a list overview.
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: 'Call this first to see what is covered before searching.' Provides context for when to use, though lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the curated, source-verified docs for building MCP servers and Claude agents. Use this whenever you need current, accurate details about MCP (transports, tools, resources, lifecycle, auth), the Claude Agent SDK, or Claude Code — instead of relying on memory, which is often stale for these fast-moving APIs. Returns ranked snippets with their source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, e.g. 'streamable http transport auth'. | |
| topic | No | Optional topic filter, e.g. 'mcp', 'agent-sdk', or 'claude-code'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure fully. It states the search returns 'ranked snippets with their source URLs' and emphasizes the data is 'curated, source-verified' and 'current, accurate', which is sufficient for a read-only search tool.
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?
Two concise sentences: the first defines purpose and scope, the second gives usage guidance and return format. No wasted words.
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?
For a search tool with no output schema, the description adequately covers return type (ranked snippets with URLs) and context (curated docs, topics). It is complete for effective agent usage.
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 100% with good parameter descriptions. The description adds value by providing an example query ('streamable http transport auth') and explaining the optional topic filter with possible values, enhancing the 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 clearly states it searches curated docs for MCP servers and Claude agents, specifying the scope (MCP, Claude Agent SDK, Claude Code) and distinguishing from sibling tools like get_doc (full doc retrieval) and list_topics (topic listing).
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 explicitly advises using this tool for current, accurate details instead of relying on memory, providing clear when-to-use guidance. However, it does not explicitly mention when not to use or directly name sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: list_topics lists all available documents, search_docs searches for specific content, and get_doc retrieves full document. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: list_topics, search_docs, get_doc. Easy to predict and understand.
With only 3 tools, the set is minimal but covers the essential operations for a documentation server: browse, search, and retrieve. It is slightly under the typical range but still reasonable for a focused server.
The tool surface covers the full lifecycle of accessing curated documentation: listing all documents, searching for specific content, and retrieving full documents. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for agentverse documentation, generated by doc2mcp.
MCP server for developer documentation, generated by doc2mcp.
MCP server for dev documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/titov-d/mcp-agentdocs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
