MCP server for PowerPoint presentation manipulation, deck generation, and slide management with approval-based mutations and audit logging
This server has 18 tools with basic schemas and descriptions, but significant quality gaps prevent production readiness. Tool names follow verb_noun convention (get_, preview_, insert_, etc.), which is good. However, descriptions are often vague and lack actionable context. Most critically: (1) Parameter descriptions are minimal or missing context about constraints and dependencies. (2) Output schemas are not documented, LLMs cannot plan downstream calls. (3) Complex nested objects like 'validated', 'position', and 'authorization' lack field-level documentation. (4) No error handling guidance, tools don't explain what to do on failure. (5) The preview/execute pattern (11 preview tools + 6 execute tools) creates cognitive load without clear differentiation in descriptions. Example: 'preview_insert_approved_deck' and 'insert_approved_deck' have identical descriptions except for 'Preview' prefix, LLMs cannot infer when to use each. The 'validated' parameter appears in 11 tools but is never explained. The 'authorization' parameter in 6 write tools is undocumented. Baseline: 90% of A+ tools have 50-200 char descriptions and ALL params described; this server averages ~80 chars with many params undescribed.
Add approved speaker notes to slides in the active presentation
Apply an approved slide specification to slides in the active presentation
Exports the active presentation as base64 so it can be archived. The caller is responsible for storing it under the engagement prefix.
Returns the active presentation id, slide count, selected slides, host platform, and add-in session id.
Returns metadata for the slides currently selected in the add-in.
Returns metadata, including generated-slide tags, for the requested slide ids.
Output schemas not documented. Tools return complex objects (e.g., slide metadata, presentation context) but LLMs cannot see what fields to expect. This breaks tool chaining and forces agents to guess at response structure.
Parameter 'validated' (object type) appears in 11 tools with no field-level documentation. LLMs cannot construct valid payloads without knowing what fields this object requires or accepts.
Parameter 'authorization' (object type) in 6 write tools is undocumented. No description of required fields (e.g., approval token structure, scope). Agents cannot construct valid authorization payloads.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Returns the theme fonts, colours, and slide dimensions of the active presentation.
Insert an approved deck specification into the active presentation
Insert approved slides into the active presentation
Preview adding approved speaker notes without mutations
Preview applying an approved slide specification without mutations
Preview inserting an approved deck specification without applying mutations
Preview inserting approved slides without applying mutations
Preview tagging generated slides without mutations
Preview updating selected generated slides without mutations
Tag generated slides in the active presentation
Reverse the last approved operation on the active presentation
Update selected generated slides in the active presentation
Preview vs. execute tools lack differentiation. 11 preview tools and 6 execute tools have nearly identical descriptions (only 'Preview' prefix differs). LLMs cannot infer when to call preview vs. execute, risking wrong tool selection.
No error handling guidance. Tools do not explain what to do on failure (e.g., 'If authorization fails, check approval token validity'). Agents have no recovery path on errors.