Loading ToolBench
MCP server for creating and reading PDF, DOCX, and PPTX documents
documents-mcp provides 6 document manipulation tools with reasonable structure but significant gaps in parameter descriptions, schema completeness, and error handling guidance. Tool naming is clear and verb-prefixed (create-*, read-*), following conventions well. However, parameter documentation is sparse and inconsistent across tools. The complex nested schemas for content arrays lack clarity on valid type unions. No output schema documentation visible. Error messages are generic and do not guide recovery. Definition quality is Fair to Good, above median for community servers but lacks polish expected of production tools.
Create a DOCX (Word) document with text, headings, lists, tables, and images
Create a PDF document with text, headings, tables, and images
Create a PPTX (PowerPoint) presentation with slides, text, images, shapes, tables, and charts
Extract text content from a DOCX (Word) file. Can also perform AI analysis if a prompt is provided.
Extract text content from a PDF file. Can also perform AI analysis if a prompt is provided.
Extract text content from a PPTX (PowerPoint) file. Can also perform AI analysis if a prompt is provided.
Complex nested oneOf schemas for content arrays lack clarity. In create-pdf and create-docx, the 'content' parameter accepts oneOf multiple object types (text, heading, table, image, pageBreak) but the schema structure is informal. No JSON Schema $discriminator hint or explicit type field to help LLMs or validators distinguish alternatives. The inline descriptions like 'type:text, content:string' are text-only and error-prone.
No output schema documentation. Tools return JSON with fields like 'success', 'filePath', 'pageCount', 'base64', 'text', 'html' but no formal schema is provided. LLMs cannot plan downstream tool calls or validate field existence without explicit documentation of return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Parameter descriptions for nested objects are incomplete. In create-pptx 'slides' array, the 'elements' parameter says 'array of slide elements (textBox, image, shape, table, chart)' but does not document the schema of each element type. No descriptions of width, height, position, styling parameters for these elements.
Error handling does not guide recovery. The handler wraps errors in JSON with 'success: false, error: message' but error messages are generic (Error.message from exceptions). No categorization of retryable vs. user-fixable errors, no suggested corrective actions, and no indication of what the LLM should do next.
Missing parameter constraints and ranges. For example, 'fontSize' in create-pdf accepts 'number' with no bounds (0 - ∞), level in headings accepts 1 - 6 but no description states this range. Color in text elements is documented as 'object with r, g, b fields' but no range (0 - 255 vs 0 - 1) is specified.
Inconsistent parameter descriptions across similar tools. 'read-pdf' and 'read-docx' both accept 'base64Content' but descriptions differ in tone and detail. 'read-docx' adds 'outputFormat' enum with description, but 'read-pdf' and 'read-pptx' lack format controls. These inconsistencies confuse agents about which tools have which capabilities.
No dry-run or confirmation pattern for destructive operations. create-* tools with outputPath parameter will overwrite existing files without warning. Agents cannot safely preview or request confirmation before executing file writes.
Gemini API integration in read-* tools requires a prompt parameter to enable AI analysis, but no description of what the Gemini model will do or how costs scale with document size. Agents cannot reason about cost/benefit of calling analysis.