Loading ToolBench
MCP server that converts .docx files to PDF via LibreOffice headless
Two tools with identical signatures and minimal descriptions. Both accept only base64-encoded docx content with no validation hints, format constraints, or error recovery guidance. Descriptions are 80-90 chars (below the 194-char baseline for A+ tools). No output schema documented. No parameter descriptions beyond the input field itself. Missing idempotency hints, retry guidance, and error classification. Tool names are verb-noun but lack clarity on the distinction between the two (one returns base64, one returns URL, not evident from names alone).
Convert a .docx file to PDF using LibreOffice headless conversion
Convert a .docx file to PDF and return a temporary download URL
No output schema documented. LLMs cannot infer what fields are returned (base64 string vs URL vs error structure). Breaks downstream tool chaining and forces agents to guess at response format.
Input parameter 'docx_base64' lacks format constraints, size limits, or validation hints. No description of what constitutes valid base64 or maximum file size. LLMs will pass arbitrary strings without validation.
Tool descriptions (80-90 chars) are below baseline (194 chars). Missing WHEN to use each tool, WHAT distinguishes them, and WHAT to expect on success/failure. Descriptions do not answer: why call convert_docx_to_pdf vs convert_docx_to_pdf_url?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
No error handling guidance. No indication of retryable vs fatal errors, no recovery hints (e.g., 'Invalid base64, ensure input is valid UTF-8 encoded base64'), no timeout or size-limit error messages.
Identical tool signatures create ambiguity. Both accept docx_base64 and differ only in output format (base64 vs URL). Names do not clearly signal this distinction. LLMs may select the wrong tool or call both unnecessarily.