Skip to main content
Glama

slide_write

Destructive

Edits to the open presentation (a file whose kind is SLIDE). Edits apply live for anyone viewing the presentation. Requires edit access. Call as {"action": "", "params": {...}}.

Read the presentation first (slide_read deck_outline or read_deck) to get slide and shape ids. Every edit returns what it wrote (new ids, placeholder shapes, z-order) and saved: false if it hadn't been confirmed yet (it is still applied).

Text content is Markdown by default (paragraphs, - bullets with two-space nesting, 1. numbering, bold, italic, strike, , , , links), or ProseMirror JSON with format: "json". Lengths are EMU unless units is "in" or "pt". Layouts: title, obj (Title and Content, the default), secHead, twoObj, twoTxTwoObj, titleOnly, blank, objTx, picTx — names or labels.

Actions: • add_slide(layout?, after_slide_id?, index?, title?, body?, notes?, format?) — Add a slide and fill its title/body placeholders. Returns the slide id and its shapes. • delete_slides(slide_ids) / duplicate_slides(slide_ids) / move_slide(slide_id, index). • update_slide(slide_id, layout?, background?, transition?, hidden?, notes?, format?) — null clears background or transition; a new layout keeps placeholder text. reset_slide(slide_id) — Put placeholders back where the layout has them (PowerPoint's Reset). • set_text(slide_id, shape_id? | placeholder?, cell?, content, format?) — Replace a shape's text; placeholder is "title", "subtitle" or "body"; cell: {row, col} for a table. • format_text(slide_id, shape_id? | placeholder?, cell?, paragraphs?, match?, case_sensitive?, whole_word?, regex?, style) — Format text in place without retyping it. style: {bold?, italic?, underline?, strike?, superscript?, subscript?, font_family?, font_size_pt?, color?, highlight?, caps: "all" | "small"?, letter_spacing_pt?, link?, align: "left" | "center" | "right" | "justify"?, line_height?, space_before_pt?, space_after_pt?, indent_pt?, list: "none" | "bullet" | "number"?}; null clears a property. Scope with paragraphs (zero-based indices as read_deck lists them) and/or match (only the matching text; paragraph properties apply to paragraphs containing a match). Omit cell on a table to format every cell. • add_shape(slide_id, shape, geometry?, xfrm?, units?, name?, text?, format?, fill?, line?, body_pr?, src?, rows?, cols?, cells?) — shape: "text_box", "shape" (with geometry e.g. rect, ellipse, rightArrow), "connector", "picture" (src data/https URL) or "table" (rows/cols or cells text). Omit xfrm for a centered default size. • update_shape(slide_id, shape_id, xfrm?, units?, name?, geometry?, fill?, line?, body_pr?, hidden?, descr?, src?, crop?) — xfrm may be partial; null removes fill, line, descr or crop. src and crop ({l?, t?, r?, b?} fractions of each edge) are for pictures. • delete_shapes(slide_id, shape_ids) / duplicate_shapes(slide_id, shape_ids) / reorder_shapes(slide_id, shape_ids, move: "front" | "back" | "forward" | "backward"). • align_shapes(slide_id, shape_ids, alignment: "left" | "center" | "right" | "top" | "middle" | "bottom") — One shape aligns to the slide, several to each other. distribute_shapes(slide_id, shape_ids, axis: "horizontal" | "vertical") — Space three or more shapes evenly. • group_shapes(slide_id, shape_ids) — Group two or more shapes; they then share a group_id. ungroup_shapes(slide_id, shape_ids) — Dissolve the groups those shapes belong to. • edit_table(slide_id, shape_id, op: "insert_row" | "delete_row" | "insert_column" | "delete_column", at). • format_table(slide_id, shape_id, style?, first_row?, band_row?, col_widths?, row_heights?, units?, cells?, cell_fill?, cell_anchor?) — Table style (mediumStyle2Accent1, lightStyle1, themedStyle1Accent1, noStyle), header row and banding, one width per column / one height per row (the table resizes to fit), and fill or text anchor (t|ctr|b) for the given cells (default all). merge_cells(slide_id, shape_id, from, to) / split_cell(slide_id, shape_id, cell) — Merge the rectangle of cells (their text joins the top-left cell) or split a merged cell again. • find_replace(find, replace, case_sensitive?, whole_word?, regex?) — Replace text throughout; replacements keep the formatting of the text they replace. • update_presentation(slide_size_preset?, slide_size?, units?, scale_content?, theme?, footer?) — slide_size_preset is "16:9" | "4:3" | "16:10", slide_size is a custom {cx, cy}; shapes scale to the new size unless scale_content is false. theme: {name?, colors?: {dk1, lt1, dk2, lt2, accent1–accent6, hlink, folHlink}, fonts?: {major, minor}} merges into the current theme. footer: {show_slide_number?, show_date?, footer_text?} or null to remove. • add_comment(slide_id, shape_id?, x?, y?, units?, text) — Start a comment thread, anchored to a shape when shape_id is given. reply_to_comment(comment_id, text) / update_comment(comment_id, text?, resolved?) / delete_comments(comment_ids). • batch(operations) — Up to 100 edits as one all-or-nothing change: {"operations": [{"action": "", "params": {...}}, ...]}. Ids created by earlier operations aren't available to later ones in the same batch.

Input Schema

NameRequiredDescriptionDefault
actionYesAction to perform: add_slide, delete_slides, move_slide, duplicate_slides, update_slide, reset_slide, set_text, format_text, add_shape, update_shape, delete_shapes, duplicate_shapes, reorder_shapes, align_shapes, distribute_shapes, group_shapes, ungroup_shapes, edit_table, format_table, merge_cells, split_cell, find_replace, update_presentation, add_comment, reply_to_comment, update_comment, delete_comments, or batch
paramsNoParameters for the action (see tool description). For batch: {operations: [{action, params}, ...]}

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations: it discloses that edits apply live to anyone viewing, that a mutation returns what it wrote plus 'saved: false' when unconfirmed, that null clears background/transition/fill/descr/crop, and that batch is all-or-nothing with ids from earlier operations unavailable to later ones. These are exactly the mutation semantics an agent cannot infer from destructiveHint=true alone.

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?

Front-loaded with purpose, prerequisites, and global conventions (Markdown, EMU units, layout names) before the action catalog, so an agent can stop reading early if it only needs the general rules. It is long, but the length is justified by 28 actions with no schema documentation; only minor redundancy in repeated list/dict syntax keeps it from a 5.

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?

For a 28-action polymorphic tool with no output schema, the description covers every action listed in the schema's action field and explains the return shape ('Every edit returns what it wrote (new ids, placeholder shapes, z-order)'), which substitutes for the missing output schema. Errors and live-coauthoring conflicts are the only unaddressed areas.

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?

The schema is a two-field dispatcher whose 'params' is an untyped object, so the description carries the entire burden and does so thoroughly: per-action parameter names, defaults ('obj' is the default layout, omitted xfrm centers the shape), enum values (geometry, alignment, table styles, 'front'/'back'/'forward'/'backward'), null-clearing behavior, and Markdown/ProseMirror plus EMU/in/pt content conventions.

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 verb and resource ('Edits to the open presentation') and narrows scope to 'a file whose kind is SLIDE', which separates it from doc_write, while slide_read is named as the read counterpart. The action list that follows makes the edit surface concrete rather than abstract.

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?

Explicitly states the prerequisite workflow ('Read the presentation first (slide_read deck_outline or read_deck) to get slide and shape ids') and the access requirement ('Requires edit access'), so an agent knows when it is eligible to call it. It also implies that batch is the route for many edits at once, but never states when *not* to use this tool relative to doc_write or when a single live edit is preferable to a batch.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.