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., "@devdocs-mcp find documentation for async/await in JavaScript"
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.
KnowledgeBase MCP server for Developer Documentation
Run directly from GitHub with ML dependencies (required for semantic search):
uvx --from "devdocs-mcp[ml] @ git+https://github.com/HellButcher/devdocs-mcp.git" devdocs-mcpAdd to your MCP client configuration (e.g., Claude Desktop, Cline):
{
"mcpServers": {
"devdocs": {
"command": "uvx",
"args": [
"--from",
"devdocs-mcp[ml] @ git+https://github.com/HellButcher/devdocs-mcp.git",
"devdocs-mcp"
]
}
}
}Clone and install with ML dependencies:
git clone https://github.com/HellButcher/devdocs-mcp.git
cd devdocs-mcp
uv sync --extra ml
uv run devdocs-mcpuvx/uv tool install resolve dependencies fresh and don't use the repo's uv.lock. If you want the exact, tested dependency versions instead, clone the repo and use the provided install script, which exports uv.lock and installs the tool constrained to it:
git clone https://github.com/HellButcher/devdocs-mcp.git
cd devdocs-mcp
./install.sh # with ML dependencies (semantic search)
./install.sh --no-ml # without ML dependencies
# then just call devdocs-mcp to run it
devdocs-mcpRelated MCP server: DevDocs MCP Server
Access to 819+ documentation sources from devdocs.io
Semantic search with vector embeddings (requires ML dependencies)
Custom local documentation sources
Efficient caching and incremental updates
10 MCP tools for documentation queries
Configuration is stored at XDG paths:
Config: ~/.config/devdocs-mcp/config.json
Cache: ~/.cache/devdocs-mcp/ (docs + embeddings)
Environment variables:
DEVD_EMBEDDING_MODEL - Override the default embedding model
Add a local directory as a documentation source.
The directory should contain HTML files that will be indexed for search.
Args: path: Absolute filesystem path to the docs directory slug: Unique identifier for this local source
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the side effect that files 'will be indexed for search,' which is useful. However, it does not mention permissions, idempotency, whether an existing source with the same slug is overwritten, or error behavior for invalid paths, leaving notable 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?
The description is concise and well-structured: a one-sentence purpose, a clarifying note about HTML files, then a clear two-line Args list. Every sentence adds value, and it is front-loaded with the core purpose.
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 relatively simple with two required parameters and an output schema (though not shown). The description covers the main action and side effect, but omits details like return value, error conditions, and idempotency. Given the lack of annotations and the presence of an output schema, a bit more behavioral context would make it more 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 0%, but the description fully compensates by explaining both parameters: 'path: Absolute filesystem path to the docs directory' and 'slug: Unique identifier for this local source.' This adds significant meaning beyond the schema's bare property names, though it stops short of specifying format constraints or validation rules.
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 function with a specific verb and resource: 'Add a local directory as a documentation source.' It distinguishes from the sibling tool add_web_source by specifying 'local directory' and is concise and unambiguous.
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 implies usage context by noting the directory should contain HTML files and that indexing will occur, but it does not explicitly state when to choose this tool over alternatives or provide caveats (e.g., prerequisites, when not to use). Sibling tool names suggest differentiation, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch documentation from a web URL (or re-download existing source).
If url is not provided, re-downloads an existing web source by slug.
By default, only fetches URLs in the same directory or below the initial URL. For example, fetching https://example.com/docs/api/index.html will only fetch files under https://example.com/docs/api/ and not https://example.com/docs/other/.
Only HTML files (.html, .htm, or no extension) are fetched and followed. Non-HTML files (CSS, JS, images, fonts, etc.) are automatically skipped.
Args: slug: Unique identifier for this web source url: Base URL to fetch from (optional for re-download) name: Display name (defaults to slug) max_depth: Recursion depth for crawling (default: 2) pattern: Regex pattern for URLs to fetch (default: .*.html?$) url_prefix: Optional URL prefix to restrict crawling (default: directory of initial URL)
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| name | No | ||
| slug | Yes | ||
| pattern | No | .*\.html?$ | |
| max_depth | No | ||
| url_prefix | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses significant behavior: directory restriction, HTML-only crawling, non-HTML skipping, and default behavior. However, it does not mention auth requirements, rate limits, or whether re-downloading overwrites existing data—minor but notable 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?
The description is well-structured with a short intro, behavioral details with an example, and a labeled Args list. Every sentence contributes useful information, balancing detail with readability.
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 6 parameters, no annotations, and an output schema, the description is sufficiently complete. It covers param semantics, defaults, crawling behavior, and edge cases like no url provided. The output schema covers return values, so no description of return format is needed.
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 0%, but the description fully compensates by explaining every parameter (slug, url, name, max_depth, pattern, url_prefix) with clear semantics and defaults. It adds meaning beyond the raw schema, such as the pattern's regex meaning and url_prefix's directory default.
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 primary action: 'Fetch documentation from a web URL', and also the secondary mode: 're-download existing source'. It distinguishes from siblings through 'web URL' vs local source, making the tool's scope explicit.
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 implies usage context: fetch from a web URL or re-download by slug. It provides a clear conditional for re-download but does not explicitly compare with alternatives like add_local_source. No exclusions are stated, but the 'web' vs local distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific documentation.
Args: slug: Documentation slug (e.g. 'javascript', 'async')
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only says 'Get detailed information' without stating that this is a read-only operation, what the output looks like, or any side effects. Minimal behavioral context is added beyond the name.
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 two concise sentences, front-loaded with the main action. Every word earns its place, and the parameter example is efficient. It avoids fluff and is easy to parse.
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, but the description does not address how it differs from 'get_document' or what 'detailed information' includes. The output schema covers return values, but the description is incomplete for tool selection given the sibling ambiguity.
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 description gives an example for the 'slug' parameter ('e.g. javascript, async'), adding semantic meaning that the schema does not provide. However, it does not explain the parameter's format, constraints, or how to find valid slugs, so compensation is partial.
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 action ('Get') and resource ('detailed information about a specific documentation'), making the purpose understandable. However, it does not distinguish itself from the sibling tool 'get_document', which likely serves a similar role, so it lacks sibling 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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, exclusions, or relationship to sibling tools, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download one or more documentation bundles from devdocs.io.
Args: slugs: Single slug string or list of documentation slugs (e.g. 'javascript' or ['javascript', 'python', 'react']) version: Optional version specifier for single slug (ignored for multiple slugs, uses latest)
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | ||
| version | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses version-handling behavior ('ignored for multiple slugs, uses latest') but does not mention side effects like filesystem writes, network requirements, or authentication needs.
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 compact and well-structured, with a one-line summary followed by a clear Args block. Every sentence adds value; there is no redundancy or filler.
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 an output schema, so return values need not be described. However, there are gaps: no mention of when to prefer this over siblings, and no disclosure of potential side effects or prerequisites beyond the parameter details. It is minimally viable but not thorough.
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 0%, but the description fully compensates. It explains that slugs accepts a single string or list of strings with concrete examples, and clarifies that version is optional and ignored for multiple slugs—details not present in the bare 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 'Download one or more documentation bundles from devdocs.io,' using a specific verb and resource. It distinguishes from siblings like get_document (which likely fetches a single document) by emphasizing bundle downloads and supporting multiple slugs.
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 implies usage when you need to download documentation bundles but does not explicitly compare to alternatives such as get_document or list_docs. There is no 'when to use' vs 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full document content by document ID from search results.
Use this to retrieve the complete content of a document after finding it via search_docs. The doc_id can be found in search results (typically shown in the path or title).
Args: doc_id: Document ID from search results (e.g. "python~3.13/library/functions#print")
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the doc_id format and source, but does not explicitly state that the operation is read-only, nor disclose error behavior, permissions, or side effects. The name 'get' implies safety, but the description lacks explicit behavioral disclosure, though this is a minor issue for such a simple retrieval 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?
The description is concise and well-structured: a clear purpose sentence, a usage sentence, and an args block with an example. Every sentence earns its place with no unnecessary repetition or fluff.
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 get tool with an output schema, the description gives all necessary context for selection and invocation: how to get the ID, when to use it, and what it returns. It could mention error handling or limitations, but such details are not critical given the tool's simplicity and the presence of an output schema.
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 schema has no descriptions for the single parameter doc_id (0% coverage). The description compensates by explaining that it is the 'Document ID from search results' and gives a concrete example, providing the agent with sufficient understanding of what to pass.
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 'Get full document content by document ID' with a specific verb and resource. It further distinguishes from siblings by tying usage to search results ('after finding it via search_docs') and clarifying that the doc_id originates from search results, which differentiates it from tools like download_doc.
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 'Use this to retrieve the complete content of a document after finding it via search_docs,' giving a clear when-to-use context. It does not list when-not-to-use or alternatives, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available documentation sources with optional filtering.
Args: source_type: Filter by 'devdocs', 'local', or None for all include_large: Include docs larger than 50 MB (default: False = exclude large) downloaded_only: only include downloaded docs (default: True = only show downloaded docs) query: Optional fuzzy text filter on doc metadata (slug, name, type, release, alias) Case-insensitive substring match. Does NOT search document content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| source_type | No | ||
| include_large | No | ||
| downloaded_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses defaults (include_large=False, downloaded_only=True), the 50MB threshold, and query semantics (metadata only, case-insensitive substring). It does not explicitly state read-only behavior, but that is inherent in 'list' and not misleading.
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 opening sentence is a crisp summary, and the Args list is scannable and well-structured. Each parameter line adds distinct value without redundancy, making the description both concise and complete.
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 has 4 optional parameters and an output schema for return structure, the description fully covers invocation semantics. It also warns that query does not search content, preventing a common misuse. This is complete for an agent to select and use correctly.
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 input schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: source_type values ('devdocs', 'local', None), include_large threshold and default, downloaded_only default, and query's matching behavior and scope. This is essential and effectively communicated.
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 lists all available documentation sources with optional filtering. The verb 'list' and resource 'documentation sources' are specific, and it differentiates from siblings like search_docs (content search) and get_document (retrieval).
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 clear context for when to use the tool (to see documentation sources) and includes an exclusion: the query parameter 'does NOT search document content,' implying that for content search you would use a different tool. However, it does not explicitly name alternative tools or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild the embedding index from downloaded documentation.
By default, only indexes newly downloaded documentation that hasn't been indexed yet. Use clean=True to rebuild everything from scratch.
Args: clean: If True, rebuild entire index from scratch. If False (default), only index missing documents. slugs: Optional list of specific doc slugs to re-index (e.g., ['vulkan', 'python']). If provided, only these docs will be processed. Ignores already-indexed status and re-indexes them.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | ||
| slugs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that by default only missing documents are indexed, clean=True rebuilds everything from scratch, and slugs ignores already-indexed status and re-indexes specified docs. This gives a solid understanding of side effects, though it could further mention impact on existing index data or concurrency.
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 and appropriately sized. It front-loads the core purpose, then uses a separate paragraph for default behavior and a bullet-like Args list for detailed parameter semantics. Every sentence adds value without unnecessary fluff.
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 moderate complexity and the presence of an output schema, the description is quite complete. It covers all operation modes, parameter effects, and the relationship to 'downloaded documentation.' It could be slightly more explicit about prerequisites (e.g., docs must be downloaded first) and interaction with removal tools, but these are minor 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?
The schema provides only parameter names, types, and defaults with 0% coverage, but the description's Args section fully explains each parameter's meaning and effect. For example, it clarifies that clean=True rebuilds entirely from scratch and that slugs accepts a list like ['vulkan', 'python'] to re-index specific docs, going well 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 opens with a clear, specific action: 'Rebuild the embedding index from downloaded documentation.' This distinctly identifies the tool's function and differentiates it from siblings like list_docs, search_docs, and download_doc, which do not perform index rebuilding.
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 on when to use the tool by explaining the default incremental behavior, the clean=True full rebuild, and the slugs parameter for targeted re-indexing. It does not explicitly mention alternatives or exclusions, but the usage modes are well specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove documentation by slug, regardless of source type.
Works for downloaded devdocs.io bundles, local sources, and web sources.
Args: slug: Documentation slug to remove (e.g. 'async')
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Remove' which implies destructive action, but does not disclose whether the operation is permanent, reversible, or what happens to underlying files vs index entries. The mention of source types adds scope context, but key behavioral traits (side effects, reversibility) are missing.
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 appropriately sized: a one-sentence purpose, a one-sentence scope clarification, and a brief args section. Every sentence earns its place, and the key detail (slug) is 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?
Given a single parameter, an output schema exists, and the tool is relatively simple, the description covers the essential aspects: what it does, what it works on, and what the slug parameter means. It lacks notes on side effects or prerequisites, but for a one-arg removal tool this is reasonably 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?
The input schema provides no description for the 'slug' parameter, and schema coverage is 0%. The description fully compensates by defining slug as 'Documentation slug to remove' and giving an example ('async'), which gives the agent clear semantic meaning.
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 begins with a clear, specific verb+resource: "Remove documentation by slug". It immediately distinguishes the tool from siblings like list_docs, search_docs, and download_doc by stating its core function and the argument (slug).
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 states "regardless of source type" and lists the supported source types (downloaded devdocs.io bundles, local sources, web sources), making it clear this is the universal removal tool. It does not explicitly name alternatives or exclusions, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documentation using semantic similarity.
Args: query: Natural language search query (e.g. "how to make HTTP requests") top_k: Number of results to return (default: 10) min_score: Minimum vector-similarity score 0.0-1.0 (default: 0.3). Applies to the semantic/vector search leg only — keyword/BM25 matches (e.g. exact title matches for bare-word queries) can still surface in results even with low semantic similarity. slugs: Optional list of doc slugs to filter by (e.g. ['javascript', 'python']) source_type: Optional source type filter ('devdocs' or 'local')
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| slugs | No | ||
| top_k | No | ||
| min_score | No | ||
| source_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral nuance, such as min_score applying only to the vector search leg and that keyword/BM25 matches may surface regardless, which provides context beyond the schema.
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 first sentence followed by a compact Args section; each item is informative and necessary.
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?
With five parameters and no annotations, the description thoroughly explains all inputs, includes examples, and notes edge-case behavior, making it sufficient given the output schema.
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?
Since schema description coverage is 0%, the description compensates by explaining each parameter's purpose, defaults, and allowed values (e.g., source_type 'devdocs' or 'local'), including caveats for min_score.
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 first sentence, 'Search documentation using semantic similarity,' clearly identifies the verb (search), resource (documentation), and method (semantic similarity), distinguishing it from sibling tools like list_docs or get_document.
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 implies usage for natural language queries but does not explicitly state when to prefer this over sibling tools like get_document or list_docs, nor does it provide exclusions or alternatives.
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.0add_local_sourceadd_web_sourcedoc_infodownload_docget_documentlist_docsrebuild_indexremove_docsearch_docsEach tool targets a distinct operation: listing, metadata, semantic search, content retrieval, download, index rebuild, removal, and adding local/web sources. There is no ambiguity or overlap between any two tools.
Most tools follow a verb_noun pattern (list_docs, search_docs, get_document, download_doc, remove_doc, rebuild_index), but 'doc_info' (noun_noun) and the add_local_source/add_web_source pair (verb_adj_noun) deviate slightly. Overall, the naming is still predictable and readable.
Nine tools is well-scoped for a documentation management server. Each tool earns its place, covering source management, search, retrieval, and maintenance without redundancy.
The tool set covers the full lifecycle: adding local/web sources, downloading docs, listing/inspecting, searching, retrieving content, removing, and rebuilding the index. There are no obvious gaps or dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
DevDocs.io keyless docs index + entry search + content (Angular, MDN, Rust, etc.).
Search and read Rust documentation for the standard library and any crate on crates.io
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HellButcher/devdocs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server