KitchenSink4PPT

Overview Schema Source Related Servers Score Discussions Admin

enable_tools

Activate optional tool packs mid-session to expand available tools and notify the client to re-fetch the list. Packs: graphics, tables-charts, design, assembly-export, review-sweeps, com, everything.

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 minimal readOnlyHint annotation by disclosing side effects: the tool list grows, the client is notified to re-fetch, the operation is idempotent, it reports approximate token cost added and the active surface, and it can be reversed with disable_tools. This is rich behavioral context that annotations do not provide.

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 description is long, but the length is justified because it must enumerate seven distinct pack names and their contents plus legacy aliases. It is front-loaded with the core action and effect, then systematically lists each pack. Some internal parentheses are dense, but the structure is understandable and every sentence contributes useful information.

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?

Despite having only one simple parameter, the description provides a complete picture: what packs are available, what each contains, legacy name resolution, idempotency, side effects on the client, cost reporting, and how to reverse the operation. Nothing essential is missing for an agent to decide whether and how to call this tool.

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 coverage is 0% and there are no enums, so the description carries the full burden of explaining the 'packs' parameter. It does this thoroughly by listing every valid pack name, including aliases for legacy names, and describing what each pack includes. This gives the agent concrete, actionable parameter values.

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?

Description uses a specific verb ('Switch on') and resource ('optional tool packs'), and clearly distinguishes itself from disable_tools by naming the inverse. It enumerates exactly which packs exist and what each contains, so an agent can understand the tool's purpose without any ambiguity.

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?

The description states this is for enabling optional tool packs mid-session, provides the full list of valid packs, and explicitly says disable_tools reverses the operation. It gives clear context for when to use the tool, though it doesn't elaborate on scenarios where it should not be used or contrast with other tools beyond disable_tools.

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