DevDocs MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists: get_page_content and get_multiple_pages both retrieve documentation content, and search_documentation and search_across_docs both handle searching, though with different scopes. The descriptions clarify the differences, but an agent might occasionally misselect between these pairs.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., clear_cache, get_page_content, search_documentation). The naming is predictable and uniform throughout the set, making it easy for agents to understand and use.
Tool Count5/5
With 12 tools, the server is well-scoped for managing DevDocs documentation. The count is reasonable, covering key operations like listing, searching, retrieving, exporting, and caching without being overwhelming or insufficient for the domain.
Completeness4/5
The tool set provides comprehensive coverage for documentation access, including listing, searching, retrieving, exporting, and caching. A minor gap is the lack of tools for updating or deleting cached documentation, but core workflows are fully supported, and agents can work around this with existing tools like clear_cache.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 states the tool shows statistics, implying a read-only operation, but doesn't clarify if it requires specific permissions, has side effects, or details the output format (e.g., structured data or plain text). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using two sentences: one states the purpose, and the other lists included statistics. Each sentence adds value without redundancy. However, it could be slightly more front-loaded by integrating the list into the first sentence for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), the description is minimally adequate. It covers the purpose and what statistics are shown, but lacks details on behavioral aspects like permissions or output format. Without annotations or an output schema, the description should do more to explain the tool's operation and results, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description adds value by listing what statistics are included (directory, total files, size, cached documentations), which provides context beyond the empty schema. This compensates adequately for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Muestra estadísticas del caché local' (Shows local cache statistics). It specifies the verb 'muestra' (shows) and resource 'estadísticas del caché local' (local cache statistics), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'clear_cache' or 'offline_mode_status', which also relate to cache operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It lists what the tool includes (directory, total files, size, cached documentations) but doesn't indicate scenarios for use, prerequisites, or comparisons to siblings like 'clear_cache' or 'offline_mode_status'. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, if it has rate limits, what authentication is required, what happens if some paths don't exist, or what the return format looks like. The examples show parameter usage but don't explain behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, the second provides usage context, and examples follow. The Spanish examples are relevant but could be more concise. Overall, most sentences earn their place, though the structure could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that fetches multiple resources, the description is incomplete. It doesn't explain what format the results come in, whether it's paginated, what happens with invalid paths, or any error conditions. For a tool with 2 required parameters and no structured output documentation, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with clear parameter documentation, so the baseline is 3. The description adds minimal value beyond the schema: the examples illustrate how parameters work together (tech with paths array), showing that 'tech' is a technology slug and 'paths' are documentation page paths. However, it doesn't add significant semantic context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtiene múltiples páginas de documentación a la vez' (gets multiple documentation pages at once). It specifies the verb ('obtiene') and resource ('páginas de documentación'), but doesn't explicitly differentiate from siblings like 'get_page_content' beyond the 'múltiples' aspect. The examples help illustrate the scope but don't provide explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Útil para obtener documentación relacionada en una sola llamada' (useful for getting related documentation in a single call). This implies when to use it (for related pages) but doesn't explicitly state when NOT to use it or mention alternatives like 'get_page_content' for single pages. The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions what the tool returns ('Muestra estadísticas: total de entradas, páginas únicas, tipos de contenido'), which is helpful, but doesn't cover other important aspects like whether it's a read-only operation, potential rate limits, authentication needs, or error conditions. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that each serve a purpose: stating the tool's function, listing what it returns, and providing usage context. It's front-loaded with the core purpose. While efficient, the second sentence could be slightly more structured (e.g., using bullet points for the statistics), but overall it's well-organized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but has gaps. It explains the purpose and usage context well, but without annotations or output schema, it should ideally provide more behavioral details (e.g., read-only nature, return format). The description covers the basics but doesn't fully compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'tech' documented as 'Slug de la tecnología'. The description doesn't add any parameter-specific information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtiene información del índice de una documentación' (Gets information from a documentation index). It specifies the verb 'obtiene' (gets) and resource 'índice de documentación' (documentation index), and distinguishes it from siblings like get_page_content or search_documentation by focusing on index statistics rather than content retrieval. However, it doesn't explicitly differentiate from get_type_entries or list_documentations, which might also relate to documentation structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Útil para entender la estructura de una documentación antes de buscar' (Useful for understanding the structure of documentation before searching). This implicitly suggests using it as a preliminary step before content-focused tools like search_documentation or get_page_content. However, it doesn't explicitly state when not to use it or name specific alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 tool is 'Útil para encontrar' items, implying it's a read-only search operation, but doesn't explicitly state it's non-destructive or safe. It doesn't disclose behavioral traits like rate limits, authentication needs, or what happens with invalid inputs. The description adds some context about requiring exact slugs but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The IMPORTANTE section efficiently handles prerequisites, and examples are relevant. However, the Spanish language might add slight cognitive load for non-Spanish agents, and the structure could be slightly tighter (e.g., combining the first two lines).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers purpose, prerequisites, and examples but lacks details about return format, error handling, or pagination (implied by 'limit' parameter). For a search tool with 3 parameters and no structured output documentation, it should provide more about what results look like or how they're structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing good documentation for all three parameters. The description adds minimal value beyond the schema: it reinforces that 'tech' requires an exact slug (implied in schema's examples) and provides example queries, but doesn't explain parameter interactions or search semantics (e.g., how 'query' matches text). Baseline 3 is appropriate since the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches within a specific documentation index and provides examples of what it finds (classes, functions, methods, modules). It distinguishes from siblings like 'search_across_docs' by specifying it searches within a single documentation index rather than across multiple. However, it doesn't explicitly contrast with 'get_documentation_index' which might retrieve the index itself rather than search within it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Primero debes saber el slug exacto de la documentación. Usa list_documentations para encontrarlo.' It provides a clear prerequisite and directs to a specific alternative tool (list_documentations) for obtaining required information. The examples also illustrate appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about potential long execution times ('Puede tomar varios minutos') and the optional max_pages parameter for limiting output, but does not cover other aspects like error handling, file overwriting behavior, or required permissions. It compensates partially but not fully for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose, followed by key details (format, warning, parameter usage), and ending with concrete examples. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (export operation with potential long runtime) and lack of annotations or output schema, the description is reasonably complete. It covers the main purpose, key behavioral traits, and parameter usage through examples, but could improve by addressing error cases or output structure more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters thoroughly. The description adds minimal value beyond the schema by mentioning max_pages in the warning and examples, but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Exporta toda la documentación') and resource ('de una tecnología'), distinguishing it from sibling tools like get_documentation_index or get_page_content which retrieve rather than export. It specifies the output format (Markdown files) and destination (local directory), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (exporting entire documentation sets to local files) and includes a warning about time for large documentations, but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for bulk exports versus single-page retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool does (extracts code/example blocks) and includes usage examples, but lacks details on behavioral traits like rate limits, error handling, or output format. It's adequate but has gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a usage guideline and examples. Every sentence earns its place, with no wasted words, making it highly efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete: it covers purpose, usage, and parameter examples, but lacks details on output format, error cases, or system behavior. For a tool with 2 parameters and 100% schema coverage, it's adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters. The description adds value by providing concrete examples (e.g., tech='python~3.10', path='library/asyncio') that illustrate parameter usage, but doesn't add new semantic details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extrae solo los bloques de código/ejemplos') and resource ('de una página de documentación'), distinguishing it from siblings like get_page_content or get_documentation_index that retrieve full content. The purpose is precise and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Útil cuando solo necesitas ver ejemplos de uso, no toda la documentación') and provides examples that clarify its scope versus alternatives like get_page_content for full documentation. This gives clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's function and provides examples of output (e.g., listing Python versions), but it doesn't mention potential limitations like pagination, rate limits, authentication needs, or what happens when no filter is applied beyond stating it lists '~600 documentaciones'. The examples add some behavioral context but leave gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief explanation of filtering, and then three concise usage examples that efficiently demonstrate key scenarios. Every sentence adds clear value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool does and provides examples, but lacks details on output format, error handling, or behavioral traits like performance or limitations. For a simple list tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing concrete examples of filter usage ('python', 'react') and illustrating the output differences, which enhances understanding beyond the schema's generic description. However, it doesn't explain parameter constraints or edge cases in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Lista todas las documentaciones') and resource ('en DevDocs'), distinguishing it from siblings like search_documentation or get_documentation_index by focusing on listing all available documentations rather than searching or retrieving specific content. The Spanish phrasing is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to list all documentations with optional filtering by technology name) and includes usage examples, but it doesn't explicitly state when not to use it or mention specific alternatives like search_documentation for more complex searches. The examples help illustrate the filtering behavior effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the filtering behavior and provides usage examples, which adds context. However, it doesn't mention important behavioral aspects like pagination (though limit parameter exists), error conditions, or what happens when no matches are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It starts with the core purpose, provides a usage prerequisite, then gives concrete examples - each sentence earns its place. No wasted words, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only filtering tool with no output schema and no annotations, the description provides good context about purpose, prerequisites, and usage examples. However, it doesn't describe the return format or structure of results, which would be helpful given the absence of output schema. The examples partially compensate for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters thoroughly. The description adds value by providing concrete examples of parameter usage (e.g., 'tech="python~3.10", entry_type="class"'), but doesn't add semantic meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('obtiene'/'gets') and resource ('entradas filtradas por tipo'/'entries filtered by type'), and distinguishes it from sibling tools by mentioning the specific filtering capability. It provides concrete examples that illustrate the exact functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('para ver los tipos disponibles'/'to see available types') and provides a clear prerequisite: 'Primero usa get_documentation_index' ('First use get_documentation_index'). This gives specific guidance on the proper sequence of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the default behavior (searching popular techs when none specified) and provides examples, which adds useful context. However, it doesn't disclose important behavioral traits like rate limits, authentication needs, response format, or pagination behavior. For a search tool with no annotations, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It starts with the core purpose, immediately provides usage guidance, explains default behavior, and gives practical examples. Every sentence earns its place with no wasted words. The information is front-loaded with the most important details first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (cross-documentation search), no annotations, and no output schema, the description is incomplete. While it covers purpose and usage well, it lacks information about the response format, result structure, error conditions, or performance characteristics. For a tool that searches across multiple documentations, the agent needs more context about what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining the default behavior when techs aren't specified (searches popular technologies) and providing concrete examples showing parameter usage. It clarifies that 'techs' is optional and shows the syntax for specific tech versions ('python~3.10'). This elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching for a term across multiple documentations simultaneously. It specifies the verb 'busca' (search) and the resource 'MÚLTIPLES documentaciones', distinguishing it from sibling tools like 'search_documentation' which likely searches within a single documentation. The description explicitly mentions this is useful when you don't know which technology to search in.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: when you don't know which technology to search in. It also specifies what happens when you don't provide techs (searches in popular technologies) and gives concrete examples showing both default and specific usage scenarios. This clearly differentiates it from alternatives like 'search_documentation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns complete content in Markdown format, requires exact paths, and has a dependency on search_documentation. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose statement first, critical requirement second, dependency guidance third, and illustrative examples last. Every sentence adds value with zero redundancy. The Spanish language doesn't affect conciseness scoring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 2 well-documented parameters and no output schema, the description is mostly complete. It explains what the tool does, when to use it, and provides examples. The main gap is lack of output format details beyond 'Markdown' (structure, size limits, error responses).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal value beyond the schema: it reinforces that 'path' must be exact and obtained from search_documentation, and provides concrete examples showing how tech and path parameters combine. However, it doesn't explain parameter formats or constraints beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('obtiene el contenido completo'), target resource ('una página de documentación'), and output format ('formato Markdown'). It distinguishes this tool from siblings like search_documentation (which finds paths) and get_multiple_pages (which handles multiple pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Necesitas el path exacto') and when to use an alternative ('Usa search_documentation para encontrarlo'). It provides clear prerequisites and distinguishes this from search tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns (which technologies have cached indexes and page counts) but doesn't disclose behavioral aspects like whether it requires authentication, has rate limits, or how current the cache status information is. The description adds basic context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: first states the core function, second specifies what information is returned, third provides usage context. No wasted words and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides good completeness: it explains what the tool does, what information it returns, and when to use it. However, without annotations or output schema, it could benefit from more detail about the return format (e.g., structured data vs plain text) to reach full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it focuses on what the tool returns instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Muestra qué documentaciones están disponibles offline') and resources ('documentaciones', 'tecnologías', 'páginas'). It distinguishes from siblings by focusing on cached/offline status rather than searching, listing, or manipulating documentation content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Útil para saber qué documentación puedes consultar sin conexión a internet.' This provides clear context about using it to determine offline availability, distinguishing it from siblings that perform operations like clearing cache, exporting, or searching documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a destructive operation ('limpia' implies removal/deletion) and explains the scope of destruction (all cache vs specific technology). However, it doesn't mention potential side effects like temporary performance impact or whether the operation requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. The first sentence states the core purpose, the second explains the two usage modes, and the examples provide immediate clarity without redundancy. Every sentence earns its place, and the information is front-loaded with the most important details first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description does an excellent job covering the essential context. It explains what the tool does, how to use it, and provides examples. The only minor gap is the lack of information about what happens after execution (success indicators, potential errors, or system state changes).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3. The description adds significant value by providing concrete examples of parameter usage ('tech="python~3.10"') and explaining the semantic difference between providing vs not providing the parameter. This goes beyond the schema's technical documentation to show practical application.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('limpia' - cleans) and resource ('caché local' - local cache). It distinguishes itself from sibling tools like get_cache_stats (which reads cache) by performing a destructive operation. The description explicitly covers both full and partial cache clearing scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use different parameter configurations: 'Sin parámetros: limpia TODO el caché' (without parameters: cleans ALL cache) versus 'tech="python~3.10": limpia solo caché de Python 3.10' (cleans only Python 3.10 cache). This gives clear alternatives within the same tool based on the user's needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![devdocs-mcp MCP server](https://glama.ai/mcp/servers/JavierDevCol/devdocs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JavierDevCol/devdocs-mcp)

Score Badge

Copy to your README.md:

[![devdocs-mcp MCP server](https://glama.ai/mcp/servers/JavierDevCol/devdocs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JavierDevCol/devdocs-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JavierDevCol/devdocs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server