Loading ToolBench
Drive a running Microsoft PowerPoint instance from Python — xlwings, but for PowerPoint, and LLM-friendly. Exposes PowerPoint automation through MCP tools for LLM agents.
pptlive defines 5 tools with reasonable descriptions (100-200 chars) and detailed input schemas. Naming is verb-noun (ppt_read, ppt_edit, ppt_render, ppt_show, ppt_batch) and action-oriented. However, schemas lack parameter descriptions, the JSON Schema shows types and enums but no 'description' field for individual parameters. This forces LLMs to infer meaning from parameter names alone, violating the pattern:tool-description requirement. Output schemas are not documented. Error handling is absent from tool definitions. The ppt_batch tool combines multiple operation types, violating single-responsibility. Overall: solid structure, but missing parameter-level documentation and output schemas.
Execute a batch of read/edit/render/show operations against a single PowerPoint attachment. All edits in the batch are fenced into one undo entry. Returns per-operation results with error tokens for failed commands.
Mutate a PowerPoint presentation: set text, format text/shapes, add/delete slides and shapes, modify animations, update theme/master styles, find and replace text, etc. All edits are fenced into a single undo entry.
Read structured data from a PowerPoint presentation: slide content, shape properties, text, formatting, animations, etc. Supports reading by anchor ID (shape, placeholder, cell, animation) or by slide/shape indices.
Render PowerPoint slides to image files (PNG, JPG, GIF, BMP, TIFF) or PDF. Supports rendering individual slides, shapes, or whole-deck snapshots. Returns both file paths and embedded base64-encoded image blocks for vision models.
Control PowerPoint presentation display: start/stop slide shows, navigate slides, read deck status and outline. Supports querying active deck, slide count, viewed slide, and presentation metadata.
Parameter descriptions missing from all input schemas. JSON Schema defines types and enums but no 'description' field for individual parameters (e.g., 'op', 'anchor_id', 'slide', 'shape'). LLMs cannot infer parameter semantics from names alone.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns both file paths and embedded base64-encoded image blocks') but formal output schema is absent. LLMs cannot plan downstream tool calls without knowing response structure.
ppt_batch combines read, edit, render, and show operations into one tool. Violates single-responsibility principle. Agents cannot compose operations granularly, they must pass all operations in one batch, reducing flexibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2025-06-18+ | v2 |
No error handling guidance in tool definitions. No recovery hints, error classification, or actionable error messages documented. If a tool fails, LLMs have no guidance on retry strategy or next steps.
ppt_edit 'op' enum is large (15+ operations) with overlapping semantics (e.g., 'format_text' vs 'master_format_text_style'). No guidance on when to use each. Consider splitting into separate tools (format_text, add_slide, delete_slide, etc.) for clarity.