KitchenSink4PPT

Overview Schema Source Related Servers Discussions Admin

Enable Tools

enable_tools

Idempotent

Enable optional tool packs mid-session to expand MCP capabilities for PowerPoint editing, notifying the client to re-fetch the updated tool list.

Instructions

Switch on optional tool packs mid-session; the tool list grows and your client is notified to re-fetch it. Packs: 'graphics' (shapes, connectors, groups, align, z-order, SVG to native editable shapes, diagram generators, images, video/audio, text boxes, run formatting, bullets, format painter, LaTeX equations); 'tables-charts' (tables: create, bulk cells, merge, row/column surgery, borders, styles, CSV/JSON; bar/line/pie/scatter/combo charts, formatting, data readback); 'design' (create FROM template, apply layouts, theme colors/fonts read AND write, brand extract/apply, layout guardrails, slide size, hide/move, autofit report, slide/master backgrounds, master and layout editing, accessibility audit/repair); 'assembly-export' (notes, sections, footers, PDF/PNG/handout export, validation, text extraction, cross-deck copy, deck merge/split, agenda slides, statistics, document properties, anonymize, custom shows, slide transitions and entrance animations); 'review-sweeps' (threaded comments, compare_decks, deck-wide font/color/language/logo sweeps, compress); 'com' (PowerPoint status, zombie check, and editing the deck OPEN in PowerPoint); 'everything' (all). The v1.0 names transitions-animations, review, sweeps, and com-live still resolve to their new homes. Idempotent; reports approx token cost added and the active surface. disable_tools reverses.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`packs`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.1Sep 9, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv1.0.0Aug 31, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by disclosing that the client is notified to re-fetch the tool list, that the operation is idempotent, that it reports approximate token cost and active surface, and that disable_tools reverses it. This gives the agent a clear model of side effects and reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is front-loaded and clear, and the pack catalog is long but necessary because the schema provides no parameter descriptions or enums. The structure is organized by pack name and capabilities, and every sentence provides useful information, though the overall length is substantial.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, the presence of an output schema, and annotations, the description is complete: it explains the side effect, pack vocabulary, aliases, idempotence, cost reporting, active surface reporting, and reversibility. No critical calling information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and packs has no enums, so the description carries the full burden. It compensates thoroughly by listing exact pack names ('graphics', 'tables-charts', 'design', etc.), their contents, and legacy alias resolution. An agent can correctly construct the packs argument from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Switch on optional tool packs mid-session' and clearly states the observable effect that the tool list grows. It also distinguishes itself from the sibling disable_tools by explicitly saying disable_tools reverses this action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly frames when to use the tool: mid-session, to enable optional packs, and gives a comprehensive catalog of pack contents to guide selection. It names disable_tools as the reversing alternative, though it does not explicitly state when not to use it or compare against other enabling mechanisms.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.