Loading ToolBench
MCP server for accessing DevDocs.io API documentation
This server has a solid foundation with 5 well-named tools and complete input schemas. All tools follow the verb_noun naming convention (list_, search_, get_) and have descriptions. However, the definitions lack critical depth: descriptions are generic and do not explain WHEN to use each tool vs others (e.g., search_doc vs search_all_docs distinction), parameter descriptions are minimal or absent, no output schemas are documented, and error handling guidance is missing. The server operates at the fair-to-good boundary, definitions are present but lack the LLM-optimization and recovery guidance expected of production tools.
Fetch the full HTML content for a specific documentation entry. Use the path from search results.
Get the complete index of entries for a specific documentation set. Useful for browsing available topics.
List all available documentation sets on DevDocs.io. Returns name, slug, version, and other metadata for each documentation.
Search across multiple documentation sets. Optionally filter by specific documentation slugs.
Search within a specific documentation set for entries matching the query. Returns matching entries with their paths and types.
Output schemas not documented. Tools return complex objects (SearchResult, IndexEntry, DocMetadata) but the server does not declare output types in tool definitions or parameter descriptions. LLMs cannot infer what fields will be returned, forcing them to guess and leading to potential runtime failures if downstream tools expect specific fields.
Tool distinctiveness not explained. The descriptions for search_doc, search_all_docs, and get_doc_index do not clearly state when to use each one vs the others. An LLM cannot determine from the descriptions alone whether to call search_doc('javascript', 'array') or search_all_docs('array') or get_doc_index('javascript') first. No guidance on search strategy or tool composition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Parameter descriptions are minimal and lack actionable format guidance. 'The slug of the documentation' does not explain valid slug formats (e.g., 'javascript', 'python~3.12', 'react'). The description includes examples but not a pattern, length bounds, or enumeration of common slugs. 'The search query' does not explain if regex is supported, max length, or case sensitivity.
No error handling or recovery guidance. The code throws generic errors ('Failed to fetch...') but the tool definitions do not document what errors are possible, whether they are retryable, or what the LLM should do next. For example, if a doc_slug is invalid, should the LLM call list_docs() to find valid slugs? This is not stated.
Result limits and pagination not documented. The code enforces limits (search_doc returns max 20 results, search_all_docs returns max 50) and filters docs by default (search_all_docs searches only top 20 docs if no filter), but these limits are not stated in the tool descriptions. An LLM may expect all results and be confused when results are truncated without indication.
get_doc_content returns raw HTML without context on parsing or encoding. The description says 'full HTML content' but does not explain: is it valid HTML5 or fragments? what character encoding? are scripts/styles stripped? should the LLM parse it with a tool or return it as-is to the user? This ambiguity may lead to malformed output.