Loading ToolBench
Documentation MCP server for fetching and storing documentation for LLMs
Four tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (fetch_, get_, search_, list_) which is good. However, descriptions are generic (avg ~80 chars, below 194-char baseline), parameters lack type constraints and detailed guidance, and output schemas are not documented. No error handling guidance, no idempotency markers, and no security considerations visible. fetch_documentation is a WRITE operation but lacks confirmation/dry-run pattern. Overall structure is present but execution is mediocre, typical of community servers landing in the 50-59 range.
Fetches documentation from a URL and stores it in the database with optional content cleaning and section extraction
Retrieves existing documentation by document ID or URL, including all chunks
Lists all available documentation with pagination support
Searches documentation using text search or semantic search (if vectors enabled)
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields. fetch_documentation, get_documentation, search_documentation, and list_documentation all lack documented return types.
fetch_documentation is a destructive WRITE operation (stores to database) but lacks confirmation/dry-run pattern and no error guidance on what to do if fetch fails or URL is invalid.
Parameter descriptions are minimal and lack constraints. 'selector' is described as 'CSS selector (optional)' but does not explain format, valid syntax, or what happens if invalid. 'limit' and 'offset' lack min/max bounds (baseline: 1-100 for page_size, 1-365 for days).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
get_documentation accepts both 'url' and 'documentId' as optional, but does not state they are mutually exclusive or what happens if both/neither are provided. LLMs will pass both, causing ambiguous behavior.
No error handling guidance. Handlers catch errors and return generic 'Failed to process message' or 'Failed to fetch documentation' without actionable recovery steps (e.g., 'URL unreachable, verify domain is accessible' or 'Document not found, try search_documentation() first').