Loading ToolBench
An MCP server for reading and extracting text and metadata from PDF files
The PDF Reader MCP has 2 tools with basic but incomplete definitions. Both tools have acceptable names (verb_noun pattern: read_pdf, get_pdf_metadata) and minimal descriptions. However, critical gaps exist: input schemas lack comprehensive descriptions for parameters, output schemas are not documented, error handling is present but lacks recovery guidance, and the tool definitions provide no guidance on when to use each tool vs. the other. The server includes input validation (file_path checks) and categorizes errors (InvalidPDF, ProcessingError, FileNotFound), but error messages do not guide the LLM toward recovery actions. Per-tool scores average to 52, placing this at the lower-middle tier of community servers.
Extracts metadata from a PDF file.
Extracts text from a PDF file.
Parameter descriptions are minimal. The 'file_path' parameter in both tools has only 'The path to the PDF file.' This does not explain the expected format, whether relative or absolute paths are accepted, or what happens on invalid paths. Per the rubric, descriptions should state 'expected format, range, and allowed values directly.'
Output schemas are not documented. The code shows tools return Dict[str, Any], but the response structure is inferred from implementation. For read_pdf, the response is {'file path': str, 'extracted_text': str}. For get_pdf_metadata, the structure depends on internal pdf_reader logic and is not visible in the provided code. LLMs cannot determine what fields to expect or how to chain these outputs to downstream tools. Per the rubric, 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Tool descriptions lack context on WHEN to use each tool. Both descriptions are simple: 'Extracts text from a PDF file.' and 'Extracts metadata from a PDF file.' The descriptions do not explain the difference, when to choose one vs. the other, or what each returns. Per the rubric, 'A tool description must answer: What does it do? When should the LLM call it instead of a similar tool? What does it return?'
Error messages are categorized but do not guide recovery. When a PDF is invalid ('InvalidPDF: PDF file could not be parsed...'), the error does not suggest what the LLM should do next (e.g., ask the user for a different file, check file integrity, or try a different format). Per the rubric, 'Error responses must tell the LLM what to do next... A raw error code or stack trace gives the agent nothing to act on.'
No distinction between tools in naming clarity. The tool names 'read_pdf' and 'get_pdf_metadata' are clear individually, but the server provides no guidance on when to call each. An LLM seeing both might assume 'read_pdf' includes metadata, or vice versa. Per the rubric, 'When multiple tools operate on the same resource, their names must make the distinction obvious.'
No pagination or limits documented for large PDFs. The read_pdf tool extracts all text without a documented limit. If a PDF has thousands of pages, the response could be enormous and exhaust the LLM context window. Per the rubric, 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50) and offer pagination.'