Skip to main content
Glama
Sign In
KitchenSink4AI

KitchenSink4PPT

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

PowerPoint Design and Masters

ppt_design
Destructive

Edit PowerPoint deck design: set slide size, layouts, theme colors and fonts, apply brand, backgrounds, master/layout placeholders, replace fonts/colors, and manage transitions or entrance animations.

Instructions

Deck design: slide size, layouts, theme colors and fonts, brand transfer, backgrounds, masters and layout placeholders, deck-wide font and color replacement, transitions and entrance animations. Theme and master reads are ppt_inspect. Every edit backs the file up first and saves atomically. Operations, one per line, as name: what it does:

  • set_slide_size: Change the slide size (16:9, 4:3, A4, Letter or inches); content is not rescaled.

  • apply_layout: Switch a slide to another layout; matching placeholders keep their content, others are reported.

  • set_theme_colors: Set any of a master's 12 theme color slots to hex colors.

  • set_theme_fonts: Set a master's theme heading and body fonts.

  • apply_brand: Apply an extract_brand result (theme colors and fonts) to every master of this deck.

  • set_slide_background: Set or clear one slide's background: a color, gradient or picture.

  • set_master_placeholder: Set a master placeholder's position, size and text defaults, which every slide inherits.

  • set_layout_placeholder: Set a layout placeholder's position, size and text defaults, for slides using that layout.

  • add_layout_placeholder: Add a placeholder to a layout; existing slides do not gain it, new slides do.

  • remove_layout_placeholder: Remove a placeholder from a layout; refuses while slides use it unless force=true.

  • insert_master_shape: Put a decoration shape (logo box, footer bar, rule line) on a master or one layout.

  • delete_master_shape: Delete a decoration shape from a master or layout by id; placeholders are refused.

  • create_layout: Create a new layout under a master, copied from an existing layout or blank.

  • set_master_background: Set the background of a master or one layout: a color or a gradient.

  • replace_fonts: Replace typefaces across the whole deck, including charts, SmartArt and unused declarations.

  • replace_colors: Replace literal colors across the deck, optionally with theme colors that follow later theme edits. More operations follow, in the same format, in the op parameter's description.

Input Schema

NameRequiredDescriptionDefault
opYesThe operation to run: one listed in this tool's description, or one of these, in the same format: - set_transition: Set or remove a slide transition (fade, push, wipe, split, cut or random). - add_entrance_animation: Add an appear, fade or wipe entrance animation to a shape, optionally paragraph by paragraph. - clear_animations: Remove a slide's animations, or one shape's; transitions stay.
argsNoThe operation's arguments as an object, including file_path unless the operation names other paths or reads no deck; unknown keys are refused. Slides count from 1 in slide_number and from 0 in slide: the user's slide 2 is slide_number 2 or slide 1. ppt_help lists every argument.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds real value on top: 'Every edit backs the file up first and saves atomically', plus per-operation consequences ('content is not rescaled', 'existing slides do not gain it, new slides do', 'refuses while slides use it unless force=true', 'transitions stay'). It stops short of describing return values or partial-failure reporting in any general way.

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 summary, the read-alternative, and the safety note are front-loaded before the operation list, and the one-line-per-operation format is scannable. The list is long, but each line carries distinct behavioral information; only the trailing pointer to the op parameter's description is slightly redundant.

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

Completeness4/5

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

For a 19-operation destructive tool with a free-form nested `args` object and no output schema, the description covers operation scope, safety semantics, and where to find argument details (ppt_help). What it omits is what a call returns or how per-slide outcomes are reported, which matters given there is no output schema to fall back on.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by glossing every enum value of `op` with its effect rather than just its name. The `args` slide-indexing convention (slide_number 1-based vs slide 0-based) is also surfaced in the schema, so no additional compensation is needed.

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?

Opens with a specific domain statement ('Deck design: slide size, layouts, theme colors and fonts, brand transfer...') and then enumerates all operations verb-by-verb, so the agent knows exactly what class of edit this tool performs. It also explicitly distinguishes reads from writes: 'Theme and master reads are ppt_inspect.'

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 routes inspection/read work to the ppt_inspect sibling and specifies that per-operation arguments live in ppt_help, giving clear entry conditions. However, it never states when to prefer this tool over the write-oriented siblings (ppt_edit, ppt_graphics, ppt_deck), so the boundary for deck-level design edits is only implied.

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

Deploy Server

Other Tools