Loading ToolBench
MCP server for Apple iWork automation — 117 tools for Numbers, Pages, and Keynote
iwork-mcp demonstrates solid tool definition fundamentals with consistent naming patterns, nearly all tools present descriptions, and explicit input schemas. However, several description texts are generic/vague, parameter descriptions could be more detailed (especially around format/constraints), and output schemas are not explicitly documented in source. The 12 sampled tools show verb_noun naming adherence (keynote_*, iwork_*), but descriptions lack context about when to use similar tools or what they return. Parameter types are present but descriptions like 'Name of the open presentation' lack actionable constraints. No parameter length limits, format specs, or error recovery guidance visible in code.
Check iwork-mcp availability on this platform
Close a Keynote presentation
Create a new Keynote presentation (optionally with a theme — use keynote_list_themes to see available themes)
Export a Keynote presentation to a different format: PDF, PowerPoint (.pptx), HTML, or images (not .key — use keynote_save_presentation for that)
Read all content from a slide: title, body, presenter notes, and list of items
Get the current theme of a Keynote presentation
List all open Keynote presentations
Parameter descriptions lack actionable constraints. E.g., 'documentName' is described as 'Name of the open presentation' but LLMs don't know: What if the name contains special chars? Is it case-sensitive? Can it be partial? What if multiple presentations are open with similar names? Add format specs and disambiguation rules.
No output schemas documented in source. While input schemas are present, LLMs cannot plan downstream calls without knowing return structure. E.g., keynote_list_presentations returns what fields? Is there pagination? What identifiers do other tools need? Document all return types explicitly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
List all slides in a presentation with their titles
List all available Keynote themes (e.g. White, Black, Gradient)
Open a .key file from disk
Save a Keynote presentation as .key (use this to save to disk — use keynote_export_presentation for PDF/PowerPoint/HTML)
Change the theme of an existing Keynote presentation (use keynote_list_themes to see available themes)
Optional parameters not clearly marked. E.g., keynote_create_presentation.themeName is optional but the description reads 'Theme name (optional, e.g. 'White', 'Black', 'Gradient')', mixing example values into descriptions invites LLMs to use those literal strings. Use formal enum constraints instead; document the default if omitted.
Destructive operations (keynote_close_presentation) lack confirmation/dry-run support. The 'saving' enum offers safety, but no explicit mention of dry-run. Agents should be able to preview consequences before committing irreversible changes.
No explicit error handling guidance in tool descriptions. E.g., keynote_open_presentation doesn't say: What if the file doesn't exist? What if it's corrupt? What if the format is unsupported? Error descriptions must guide LLMs on recovery actions.
Enum values inconsistently formatted. keynote_close_presentation.saving uses lowercase 'yes', 'no', 'ask' but keynote_export_presentation.format uses PascalCase 'PDF', 'PowerPoint', 'HTML', 'images'. Standardize on one convention (prefer lowercase with underscores) to reduce LLM confusion.