Loading ToolBench
MCP server for PowerPoint presentation manipulation using Spire.Presentation library
This server has persistent, foundational issues across naming, descriptions, and schemas. While most tools are registered with JSON Schema objects, the schemas are frequently incomplete (missing type annotations, minimal constraints), and descriptions lack the specificity needed for LLM tool selection. Several tools have ambiguous names ('create_slide' vs 'append_slide', typo in 'presentaion') and descriptions under 30 characters that fail to explain WHEN to use the tool or what it returns. Error handling is minimal, most tools return flat error strings ('Error: <message>') without guidance on next steps. Per-tool analysis reveals only 2 out of 10 tools merit scores above 50; the median is ~38, well below production baseline.
Adds a chart to a specified slide in a PowerPoint presentation.
Adds a geometric shape to a specified slide in a PowerPoint presentation.
Adds a new text shape or updates an existing one on a specified slide in a PowerPoint presentation.
Convert Ppt presentation to different formats.
Creates a new Ppt presentation.
Creates a new slide in an existing presentaion.
Creates a SmartArt graphic on a specified slide in a PowerPoint presentation.
Multiple tool descriptions are too short (<30 chars) and lack context for LLM selection. E.g., 'Creates a new slide in an existing presentaion' (note typo), 'Adds a chart to a specified slide', no explanation of when to use vs. alternatives, no return value documentation.
Ambiguous naming: 'create_slide' uses 'Ppt' terminology but codebase internally calls the implementation 'append_slide'. Tool names should match user intent; 'append_slide' is clearer about appending to existing presentations. Also, inconsistent capitalization ('Ppt' vs 'PPT' vs 'ppt').
Input schemas lack critical constraints: numeric params (x, y, width, height, slide_num) have no minimum/maximum bounds. This allows LLMs to pass negative coordinates, zero dimensions, or out-of-range slide indices, causing silent failures. E.g., 'add_shape' accepts x=-100 or width=0 without validation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Creates a table on a specified slide in a PowerPoint presentation.
Deletes a shape from a specified slide in a PowerPoint presentation.
Deletes a slide from an existing presentation.
Error handling is non-actionable. Tools return flat strings like 'Error: <message>' without guidance on next steps. E.g., if delete_slide fails because slide_num is out of range, the LLM receives 'Error: ...' with no suggestion to call a tool to list available slides or retry with a different index.
No output schemas documented for most tools. The code shows tools return success/failure strings or dicts (e.g., add_shape returns {'success': bool, 'message': str, 'shape_info': dict}), but this structure is not explicit in the MCP tool definitions, forcing LLMs to guess what fields to expect.
Parameter descriptions lack operational guidance. E.g., 'shape_type' lists examples ('Rectangle', 'Oval', 'Arrow', 'TextBox') in the description text rather than as an enum constraint. LLMs treat examples as suggestions, not exhaustive options, and will hallucinate unsupported shape types. All enum-like parameters should use JSON Schema enum constraints.
No discovery/introspection tools. The server provides 10 mutation tools but no tool to list available slide layouts, SmartArt types, or chart types. Agents must guess valid enums or trial-and-error, wasting rounds.
Destructive tools (delete_slide, delete_shape) lack confirmation/dry-run patterns. An agent could accidentally delete a critical slide from a user's presentation without warnings or undo capability.
Typo in description: 'create_slide' says 'presentaion' instead of 'presentation'. This signals poor polish and may confuse parsing.