Loading ToolBench
Model Context Protocol server for GuruPDF — convert, compress, merge and edit PDFs and 100+ file formats from any AI agent (Claude, Cursor, VS Code, Windsurf).
GuruPDF MCP has three tools with mixed definition quality. Tool naming follows verb_noun convention (convert_, get_, list_) and is reasonably clear. Descriptions are present and substantive (200+ chars for convert_file). However, parameter schemas are only partially visible in the source, the code shows Zod schema definitions but the actual parameter-level descriptions are partially cut off in the provided excerpt. Error handling via the friendly() function maps GuruPDF-specific errors to user-friendly messages, which is good. The main gaps: (1) no parameter constraint documentation (e.g., what are valid 'to' formats?), (2) no documented output schema structure, (3) no pagination for list_conversions despite it potentially returning large result sets, (4) tool descriptions lack clarity on prerequisites (e.g., 'Requires GURUPDF_API_KEY env var').
Convert or process a local file (or URL) with GuruPDF. Convert between 100+ formats (PDF ⇄ Word/Excel/PowerPoint, images, ebooks, etc.) or run a PDF tool (compress, merge, split, rotate, protect, watermark, OCR…). Saves the result next to the input and returns the path.
Check a GuruPDF conversion job by its id (uuid). If it's finished, downloads the result to disk.
List the conversions and tools GuruPDF supports, optionally filtered by an input file format.
Parameter constraints not documented. 'to' parameter in convert_file accepts either a format string or tool slug, but no constraint is provided explaining valid values. LLMs will hallucinate formats. Should declare enum or provide discovery guidance.
Output schemas not documented. Tools return text responses via text() helper, but the actual structure of returned data (e.g., file paths, job IDs, conversion lists) is not visible in tool definitions. LLMs cannot plan downstream calls without knowing what fields to extract.
list_conversions lacks pagination. Tool may return large result sets but provides no limit or offset parameters. LLMs will receive unbounded lists, wasting context. Should cap results and return pagination tokens.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Prerequisites not stated in descriptions. All tools require GURUPDF_API_KEY env var, but this is not mentioned in tool descriptions. Tool descriptions should say 'Requires GURUPDF_API_KEY environment variable' so agents know when the tool is unavailable.
Error messages lack recovery guidance. The friendly() function maps errors to user-readable text, but does not suggest next steps. E.g., for 'tool not found', the error suggests list_conversions, which is good, but other errors (rate limit, credits) do not suggest alternatives.
Parameter descriptions lack format/range guidance. 'wait' parameter is described as 'Wait for the result (default true)' but does not explain timeout behavior or what happens if wait=false (returns job ID). 'output_dir' defaults to input folder but this is not stated as a default in the schema.