Loading ToolBench
Full-featured PowerPoint MCP server for macOS that drives the live Microsoft PowerPoint app via AppleScript (not OOXML editing). 21 tools covering lifecycle, slide editing, shape editing, and inline visual feedback.
Two tools with clear verb-noun naming (pptx_add_slide, pptx_add_slide_from_template) and detailed descriptions (150+ chars each). Input schemas present with type definitions and descriptions for all parameters. However, output schemas are not documented, callers cannot see what fields are returned. Descriptions are verbose and include implementation caveats (AppleScript quirks, corporate template notes) that belong in comments, not user-facing docs. Parameter descriptions are good but lack explicit constraints (e.g., no enum for layout values despite mentioning ~30 standard options). No error handling guidance, LLMs won't know what to do if a slide operation fails.
Add a new slide to the active presentation with one of PowerPoint's built-in layouts. Use this instead of upstream `add_slide` — that one is broken (#20473). Note: `layout` is a *built-in* PowerPoint enum, NOT a corporate template's custom layout. PowerPoint Mac AppleScript exposes ~30 standard slide layouts (blank, title, title only, text, chart, etc.). Setting a custom layout from a corporate template via AppleScript is not exposed — you'd need to use python-pptx + slide layout XML references for that. Common enum values: blank, title, title only, text, two column text, chart, text and chart, organization chart, table, vertical title and text, title and content, section header, two content, comparison.
Clone an existing slide via PowerPoint's clipboard — full visual copy. The new slide inherits every style detail from the source: layout placeholders, fonts, theme colors, AND any freeform decorative shapes the author drew on top (rectangles, custom icons, hand-placed text boxes — all of it).
Output schemas not documented. Callers cannot see what fields are returned (e.g., does add_slide return slide_id, slide_index, or just success?). LLMs cannot plan downstream tool calls without knowing the response structure.
Layout parameter accepts free-form strings instead of an enum. Description mentions ~30 standard values (blank, title, chart, etc.) but does not constrain input. LLMs will hallucinate invalid layout names.
Descriptions include implementation details (AppleScript dictionary quirks, corporate template caveats, sandbox paths) that confuse LLMs. User-facing descriptions should focus on WHAT the tool does and WHEN to use it, not HOW it works internally.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
No error handling guidance. If add_slide fails (e.g., invalid layout, presentation closed), the description does not tell LLMs what to do next. Should include recovery hints like 'If layout is invalid, call list_available_layouts() first.'
Position parameter is nullable but no guidance on default behavior. Description says 'If omitted, the slide is appended at the end', this should be explicit in the schema (default: null or omit entirely).