Loading ToolBench
MCP server for fetching and searching documentation
This is a well-structured documentation MCP server with clear tool naming, comprehensive parameter schemas, and mostly good descriptions. All 10 tools follow verb_noun naming conventions and have documented input schemas with proper type definitions. Most tools include good descriptions (average ~180 chars), though a few are brief. Schemas are substantially complete with typed parameters and descriptions. Error handling is present but could be more prescriptive for recovery paths. Output schemas are not explicitly documented in the visible code. The server demonstrates strong composition, tools are single-purpose and chainable. However, there are gaps in error guidance and output schema documentation that prevent a higher score.
Tool for attempting to cancel a pipeline job.
Tool for fetching a single URL and converting its content to Markdown. Unlike scrape_docs, this tool only processes one page without crawling or storing the content. Supports both HTTP/HTTPS URLs and local file URLs (file://).
Tool for finding the best matching version of a library in the store. Supports exact version matches and X-Range patterns (e.g., '5.x', '5.2.x').
Tool for retrieving simplified information about a specific pipeline job.
Tool for listing pipeline jobs managed by the pipeline. Allows filtering jobs by their status.
Tool for listing all available libraries and their indexed versions in the store.
Tool for refreshing an existing library version by re-scraping all pages and using ETag comparison to skip unchanged content.
Output schemas are not documented in visible source code. While input schemas are comprehensive, the expected return types for each tool are not explicitly declared, making it harder for LLMs to plan downstream calls and extract relevant fields.
Error handling lacks prescriptive recovery guidance. Tools declare their logic but do not return actionable next steps when operations fail. For example, scrape_docs or refresh_docs may fail due to network issues, parsing errors, or timeouts, but the error response does not guide the agent toward retry logic or alternative approaches.
remove_docs is a destructive tool but lacks a dry-run or confirmation mechanism. Agents may inadvertently delete documentation without verification. No confirmation-request pattern is visible in the source.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Tool to remove indexed documentation for a specific library version. This class provides the core logic, intended to be called by the McpServer.
Tool for enqueuing documentation scraping jobs via the pipeline.
Tool for searching indexed documentation. Supports exact version matches and version range patterns. Returns available versions when requested version is not found.
Brief tool descriptions for list_jobs, get_job_info, and cancel_job lack context about when to use them relative to other job-management operations. Descriptions are between 50-75 characters, below the optimal 80-200 char range for LLM selection.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible in the source code. The FEATURES report indicates toolAnnotations=false. This means the LLM cannot automatically infer which tools are safe to retry, which modify state, and which are read-only, requiring the LLM to rely entirely on descriptions.
Parameter descriptions for optional parameters (e.g., 'targetVersion' in find_version, 'version' in scrape_docs) do not state what happens if the parameter is omitted. This leaves LLMs uncertain whether to always pass a value or rely on a default behavior.
scrape_docs and refresh_docs accept 'url' and other parameters but do not validate or document what HTTP errors or parsing failures will return. No guidance on retryable vs. fatal failures.