Click on "Deploy 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., "@devdocs-mcp search the Vite docs for defineConfig and show the top result"
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 (stdio) server that gives AI agents token-efficient access to DevDocs documentation. Docsets are fetched once as static JSON from DevDocs' own endpoints, cached locally, and served offline as compact rows and markdown — no DevDocs fork, no Docker, no browser.
pnpm install
pnpm buildNode 20+ required (uses global fetch).
Related MCP server: MCP Framework Documentation Server
All harnesses run the same thing: node /absolute/path/to/devdocs-mcp/dist/index.js
over stdio. Substitute your real absolute path below.
claude mcp add devdocs -- node /absolute/path/to/devdocs-mcp/dist/index.jsAdd --scope user to register it for all projects instead of the current one.
mcpServers JSON blockClaude Desktop (claude_desktop_config.json), Cursor (.cursor/mcp.json),
Cline, Windsurf, VS Code (.vscode/mcp.json, under "servers"), and most
other MCP clients:
{
"mcpServers": {
"devdocs": {
"command": "node",
"args": ["/absolute/path/to/devdocs-mcp/dist/index.js"]
}
}
}In ~/.codex/config.toml:
[mcp_servers.devdocs]
command = "node"
args = ["/absolute/path/to/devdocs-mcp/dist/index.js"]dsh has no built-in MCP support — it comes from the official bridge plugin,
one plugin instance per MCP server, wired per profile (headless, web,
tui):
dsh plugin --profile headless add @deepseek-ai/dsh-mcp-client@0.0.1-rc.1(The declares no dsh.bundle — installed as a plain dependency warning is
normal; it means manual wiring is required.) Then add an insert block to
$DSH_HOME/profiles/headless/cordis.patch.yml — a bare - id: row would be
treated as an override of an existing entry and fail:
- insert:
- id: mcp-devdocs
name: "@deepseek-ai/dsh-mcp-client"
config:
serverName: devdocs
transport: stdio
command: node
args: ["/absolute/path/to/devdocs-mcp/dist/index.js"]
# failOnStartupError: true # enable while debugging: loud failuresVerify with dsh --profile headless --dump-config | grep -A6 mcp-devdocs,
then a live probe (dsh startup failures are silent by default):
dsh --profile headless "use the devdocs list_docsets tool; if no devdocs tools are available say NO-TOOLS"Tools appear to the model as mcp__devdocs__<tool> in dsh and Claude Code.
Tool | Arguments | What it returns |
|
| Cached docsets ( |
|
| Downloads |
|
| Deletes that docset from the cache |
|
| Fuzzy entry-name matches as |
|
| Page as markdown. |
|
| Heading outline as |
Typical flow: list_docsets {installed:false, filter:"vite"} →
install_docset {slug:"vite"} → search {query:"defineConfig"} →
toc / read with the path from the search rows.
The tools are self-describing, but agents won't form the habit of checking
DevDocs on their own. Paste this into your project's AGENTS.md / CLAUDE.md
(or your global one), and edit the docset list for your stack:
## Documentation lookup (devdocs MCP)
Before writing code against a library or API you haven't recently worked
with, check its documentation via the `devdocs` MCP tools — don't guess
from memory and don't reach for web search first. The docs are local,
offline, and current.
- One-time per docset: `install_docset` (find slugs with
`list_docsets {installed: false, filter: "..."}`). This project uses:
`typescript`, `react`, `vite`, `node`.
- Lookup flow: `search {query}` → pick a row → `toc {docset, path}` →
`read {docset, path: "page#anchor"}` for just the section you need.
Read whole pages only when short; follow `offset` hints to continue.
- If `search` misses, try a shorter query or the docset's own naming
(e.g. "shared options" rather than "defineConfig options").~/.cache/devdocs-mcp/ by default, overridable with DEVDOCS_CACHE_DIR:
docs.json # DevDocs manifest, refreshed when older than 24h
<slug>/index.json # entry list
<slug>/db.json # page path -> HTML
<slug>/meta.json # {slug, name, release, mtime, installedAt}The cache is shared across sessions; delete a <slug>/ directory (or call
remove_docset) to reclaim space.
pnpm test # vitest, fully offline (fixtures only)
pnpm build # tsc -> dist/
pnpm smoke # live: spawns dist/index.js, installs vite, searches/reads/tocsUnit tests cover the pure modules (search, render, path handling); the six
tool handlers are thin wiring over those and are exercised end-to-end by the
smoke script instead.
Documentation content comes from DevDocs (maintained by freeCodeCamp), which aggregates and re-publishes the documentation of each upstream project. This server only fetches and reformats it: all content remains under the license and copyright of its respective upstream project, and each docset's attribution is included in the DevDocs manifest.
Download a DevDocs docset into the local cache (re-downloads only if upstream is newer).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Docset slug, e.g. 'vite'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the specific behavior 're-downloads only if upstream is newer' and the action 'Download', but it omits details about potential side effects such as overwriting existing cache entries or network requirements.
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?
A single well-written sentence covers the action, the target, and the key idempotency behavior. No unnecessary words or redundant information are included, and the main verb is appropriately front-loaded.
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 tool with only one parameter, no output schema, and no annotations, the description covers the essential context:, the command, what gets downloaded, where it goes, and the caching update policy. It is missing potential edge-case details like error handling, but those are not required for correct invocation.
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?
The parameter `slug` is already fully documented in the schema with a definition and example ('Docset slug, e.g. 'vite''), achieving 100% schema coverage. The description adds no additional information about the parameter's meaning or syntax beyond that baseline.
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 identifies the verb ('Download'), resource ('DevDocs docset'), and target ('local cache'). This distinguishes it from siblings like remove_docset and list_docsets, which handle deletion and listing, respectively.
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 does not explicitly say when to use this tool versus alternatives or when not to use it. While its purpose implies its use for installing docsets, no direct guidance or written mention of alternatives exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed (cached) docsets, or search the DevDocs catalog for installable ones (installed=false requires filter).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Substring match on slug or name. | |
| installed | No | true: cached docsets. false: search the DevDocs catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals that installed=false requires a filter and that the catalog path is for installable docsets, which is useful. However, it does not disclose what happens if the filter is omitted (error vs empty result), whether network access is involved, or the general return shape, leaving behavioral cliff.
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 entire description is a single sentence with no filler. It front-loads the core action, then packages the alternate mode and a critical constraint in a parenthetical. Every word contributes value.
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 tool with two optional parameters and no output schema, the description covers the main execution paths and a key invocation rule. It lacks detail on error behavior when the filter is missing and on the response format, but it is mostly sufficient for an agent to call the tool reasonably.
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 100%, so the baseline is 3. The description adds meaningful cross-parameter semantics not present in the schema: it states that installed=false requires a filter, linking the two parameters in a way the schema does not. This exceeded the baseline.
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 explicitly names the action ('List') and the resource (docsets), and it distinguishes two operating modes: listing cached docsets vs searching the DevDocs catalog. It is clear about its primary functionality, though it does not explicitly differentiate itself from the sibling 'search' tool, so it stops short of a full sibling-distinguishing statement.
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 gives clear guidance about how to select each behavior through the 'installed' flag, and it states an important constraint ('installed=false requires filter'). It does not, however, mention when to prefer the alternative sibling tools (e.g., 'search' or 'install_docset'), so it lacks explicit into tool-vs-tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a docset page as markdown. Append #anchor to the path to get just that section. Long pages paginate via offset.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Page path from search/toc, optionally with #anchor. | |
| docset | Yes | Docset slug, e.g. 'vite'. | |
| offset | No | Character offset into the markdown (from a truncation hint). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses the markdown output, the #anchor behavior, and pagination via offset. This is solid coverage for a read-only tool, though it omits error behavior and the precise pagination protocol.
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, with the primary purpose front-loaded and the pagination detail following naturally. Every sentence earns its place with no 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?
For a simple read tool, the description covers the core behavior, markdown output, section anchoring, and pagination. It does not address errors or absent pages, but the missing details are unlikely to block correct invocation.
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 100%, but the description adds meaning beyond the schema by explaining how #anchor affects the path and that long pages paginate via offset. This enriches the schema's bare parameter definitions.
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 'Read a docset page as markdown' — a specific verb and resource. This distinguishes it from sibling tools like remove_docset, search, toc, and install_docset.
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 does not explicitly state when to use this tool versus alternatives such as search or toc. The path schema hints that paths come from search/toc, but the description itself gives no usage guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a docset from the local cache.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Docset slug, e.g. 'vite'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates the destructive action and the specific scope ('local cache'), but it does not state whether deletion is permanent, what happens for a missing slug, or whether any side effects occur for dependent features like search or read.
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 a single short sentence with no wasted words. It is front-loaded with the core action and includes the useful 'local cache' qualifier 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?
The tool is simple and has one well-documented parameter, so the description is minimally viable. However, with no annotations and no output schema, an agent would benefit from more detail about result/error behavior and reversibility, making the definition adequate but not fully complete.
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 100%, and the schema already fully documents the single 'slug' parameter with an example. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 applies.
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 a clear verb ('Delete') and a clear resource ('a docset from the local cache'), making the action unambiguous. It also distinguishes this tool from siblings like install_docset and list_docsets by focusing specifically on cache deletion.
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 gives no guidance about when to use this tool versus alternatives such as install_docset or list_docsets. It also does not mention prerequisites, such as the docset needing to already exist in the local cache, or when deletion might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy search entry names across installed docsets. Returns compact rows: slug, type, name, path. Feed a path to read/toc.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Entry name to look for, e.g. 'defineConfig'. | |
| docsets | No | Limit to these slugs (default: all installed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the fuzzy matching behavior and the exact output shape ('compact rows: slug, type, name, path'), plus the path's role in follow-up tools. It does not cover edge cases like empty results or sorting, but for a read-only search these are minor gaps.
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 sentences, front-loaded with the core operation, followed by output details and a workflow hint. No filler; every clause contributes meaningfully.
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?
The tool is simple (3 params, no output schema, no annotations). The description covers purpose, return format, and how to use the result via read/toc. It omits edge cases like no-match behavior, but for a search tool it is largely complete and does most of the work in the absence of 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 67%: query and docsets have descriptions, while limit has only type/default/min/max. The description adds context by explaining the query is fuzzy and that docsets are installed slugs, but it does not elaborate on limit beyond schema constraints. This provides marginal extra value, so a 3 is appropriate.
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 a specific verb and resource: 'Fuzzy search entry names across installed docsets.' It also lists the output fields and the follow-up workflow ('Feed a path to read/toc'), which clearly distinguishes it from siblings like list_docsets (lists docsets) and read/toc (consume paths).
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 provides clear context: search is the entry point for locating entries, and the line 'Feed a path to read/toc' tells the agent when to use read/toc after search. It does not explicitly mention alternatives or when not to use this tool, but the workflow hint gives practical selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heading outline of a page: level, title, anchor. Pick a section and read path#anchor instead of paging the whole page.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Page path (any #anchor is ignored). | |
| docset | Yes | Docset slug, e.g. 'vite'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately conveys that the tool provides a navigation outline rather than full page content, which is the key behavioral trait. It could mention that no page text is returned, but 'heading outline' and the anchor-based reading tip make this sufficiently clear.
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 short sentences, no fluff. The output contents are front-loaded, and the usage guidance is compact and actionable.
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 two-parameter tool with no output schema, the description is sufficient: it states what the result contains, how to use it, and how to proceed with a sibling tool. Nothing necessary for correct invocation is missing.
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 100%, so the schema already documents docset and path. The description adds useful workflow context around path#anchor, but it does not need to redefine parameters. Baseline 3 is appropriate.
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 identifies what the tool returns — a heading outline with level, title, and anchor — and names the page as the resource. It lacks an explicit action verb like 'returns' or 'lists', but the meaning is unambiguous and distinguishes it from read/search siblings.
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?
It gives explicit guidance: use this tool to pick a section, then read path#anchor instead of reading the whole page. This directly addresses when to use it versus the read sibling and gives a concrete workflow.
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.
v0.1.0install_docsetlist_docsetsreadremove_docsetsearchtocScored across 6 tools
Each tool has a clearly distinct purpose: three manage docsets (list, install, remove) and three navigate content (search, read, toc). There is no overlap or ambiguity.
The first three tools follow a consistent verb_noun snake_case pattern (remove_docset, list_docsets, install_docset), but the remaining three use bare verbs or a noun (search, read, toc). This mixed convention is readable but not fully consistent.
With 6 tools, the server is well-scoped for its purpose of managing and reading DevDocs documentation. Each tool earns its place and there is no bloat.
The server covers the full lifecycle: list/install/remove docsets and search/read/navigate pages. The install tool also handles updates, leaving no obvious gaps for the stated purpose.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
