Loading ToolBench
Universal MCP server for extracting text from various document formats
The server provides 7 document-processing tools with reasonable naming (verb-noun convention) and basic schemas. However, most tool descriptions are short and lack context about prerequisites, error conditions, and when to use one tool over another. Parameter descriptions are present but often minimal. Output schemas are not documented. Error handling is minimal, the code shows basic validation but no guidance for LLM recovery. Notably, batch_read_documents duplicates functionality of read_document with an array parameter; this violates single-responsibility and composition patterns. The rate limiter and output truncation logic are present but not exposed to the agent via error messages that guide recovery. Security is reasonable (no credentials in parameters), but logging and audit trail are absent. Overall, these tools are functional for a developer but underpowered for a production agent system.
Read multiple documents at once and return combined output
Convert various document formats to Markdown format for better formatting preservation
Extract images from PDF files and save them to the specified output directory
Extract metadata from a document file (file size, format, page/sheet count, encoding, etc.)
List all document formats supported by the reader with their capabilities
Read and extract text content from various document formats (PDF, XLSX, CSV, DOCX, TXT, JSON, Markdown)
Search for specific text content within a document and return matching excerpts
Output schemas not documented. LLMs cannot infer what fields to expect in responses, making downstream composition and data extraction difficult. No explicit documentation of whether tools return strings, objects, lists, or structured data.
batch_read_documents duplicates read_document functionality (accepts array vs single path). This violates single-responsibility principle. Agents should compose multiple calls to read_document instead; a batch variant without clear performance/semantic distinction confuses the LLM into choosing between nearly identical tools.
Error handling provides no recovery guidance. Code enforces rate limits and output truncation (seen in _enforce_rate_limit and _truncate_output_if_needed) but tools do not return actionable error messages. An LLM receiving 'Rate limit exceeded' has no guidance on retry strategy, backoff, or alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool descriptions are under 100 characters and lack WHEN-to-use context. 'Read and extract text content from various document formats' tells WHAT but not WHEN to prefer this over convert_to_markdown or search_in_document. Baseline from production tools: 194 chars avg. These average ~80 chars.
No logging or audit trail. Code has logger.getLogger but no explicit audit of which documents were read, by whom, when, or what was extracted. For sensitive document processing, traceability is critical. Missing: who invoked the tool, what parameters, what was extracted.
Parameter validation rules not documented in descriptions. max_pages and max_rows accept integers but no guidance on negative, zero, or absurdly high values. Description should state: 'max_pages: number of pages to extract (1 - 999, default 50). Use 0 for all pages.'
No mention of supported file formats in parameter descriptions. read_document accepts path but doesn't state which formats are valid. An LLM may pass .zip or .ppt and get a cryptic error. Should link to list_supported_formats or state formats inline.