Loading ToolBench
Model Context Protocol server for hierarchical documentation navigation with markdown and OpenAPI support
Server provides 7 tools with complete input schemas and descriptions, but descriptions are often generic and lack actionable LLM guidance. All tools are read-only except generate_pdf_release. Naming is clear and verb-based, but parameter descriptions could be more prescriptive about constraints, valid ranges, and error recovery paths. Output schemas are partially documented in handler code but not fully specified in tool definitions. Error handling is present but minimal, exceptions are caught and logged, but error responses lack recovery guidance.
Generate a PDF documentation release with optional metadata and confidentiality marking
Get all available tags in the documentation with optional tag frequency counts
Retrieve the full content of a specific document by URI
Get the table of contents for the documentation with optional depth limit
Navigate to a specific URI in the documentation hierarchy and retrieve navigation context
Search documentation by tags with optional category filter
Search across markdown documents with full-text search capabilities
Descriptions lack actionable LLM guidance. Examples: 'Search documentation content by query with optional category filtering' (74 chars) is factual but does not explain WHEN to use this tool vs search_by_tags, what output format to expect, or how to handle no results.
Parameter descriptions are minimal and lack constraint specifications. Example: 'limit' parameter on search_documentation has description 'Maximum number of results to return' but does not specify valid range (e.g. 1-100, default 20). LLMs cannot infer whether to pass 1000 or 5.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 14 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Output schemas are not documented in tool definitions. Handler functions return structured dicts (e.g. 'uri', 'title', 'excerpt', 'breadcrumbs', 'category', 'relevance', 'match_type' for search_documentation) but these fields are not declared in the MCP tool schema. Per pattern, 100% of A+ tools have documented return types so LLMs know what to expect and can chain results to downstream tools.
Error handling is generic and lacks recovery guidance. Code shows 'except Exception as e: return [{"error": str(e)}]', a bare error string gives LLMs no actionable next step. Per pattern:recovery-guide, errors must tell the LLM what to do: 'URI not found. Try get_table_of_contents() to discover valid URIs.'
generate_pdf_release tool has poorly specified behavior. Description is vague ('Generate a PDF documentation release using the generate-docs-pdf.sh script with optional metadata and confidential flag', 129 chars, lacks WHEN to use, what the script does, or error modes). This is the only write/destructive tool but lacks a confirmation/dry-run pattern to prevent accidental releases.
Tools lack clarity on chaining. If search_documentation returns results, what parameters do downstream tools (navigate_to, get_document) expect? The 'uri' field returned from search must match the 'uri' parameter accepted by navigate_to and get_document, but this dependency is not documented. Per pattern:tool-chain, tool A's output must contain the IDs and references tool B needs.
Tag search semantics are unclear. 'Search documentation by tags' could mean OR (match any tag) or AND (match all tags). Parameter description 'List of tags to search for' does not clarify.
No pagination support in list-like tools. search_documentation accepts 'limit' but no 'offset' or 'page' parameter. Per pattern:paginated-result, tools returning lists should support offset/limit and return a total_count or next_cursor. Without pagination, 1000-result searches could blow the context window.