Skip to main content
Glama

manage_shape

Destructive

Modify or remove an existing slide element—text box, shape, picture, chart, table, or placeholder—by deleting, clearing text, resizing, restacking, or moving it to another slide.

Instructions

Change or remove one existing element (text box, shape, picture, icon, chart, table, placeholder) on a slide.

Find shape_index with get_slide_info, which lists every element with its text and position. Indexes are 0-based and shift down by one after a delete or move_to_slide, so re-read get_slide_info before a second call on the same slide (or work from the highest index down).

operation:

  • "delete": remove the element. A placeholder's text is cleared instead, since the slide layout would otherwise show its prompt.

  • "clear_text": empty the element's text, keeping it and its format (for a table, every cell).

  • "set_geometry": move and/or resize — left, top, width, height in inches; pass only what changes.

  • "bring_to_front" / "send_to_back": restack it above or below every other element on the slide.

  • "move_to_slide": move it to target_slide_index (0-based) at the same position (or at left/top if given). Use this for content built on the wrong slide. A placeholder's text moves into the target's matching placeholder.

To replace an element's content, prefer editing it in place (populate_placeholder, manage_text) over deleting and re-adding it — the element keeps its template formatting that way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNo
leftNo
widthNo
heightNo
operationYes
shape_indexYes
slide_indexYes
presentation_idYes
target_slide_indexNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.10.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses important nuances: deleting a placeholder clears its text instead of removing it, clear_text preserves the element and format, and move_to_slide carries placeholder text into the matching placeholder. These behavioral details are not inferable from annotations alone and materially affect how the tool should be invoked.

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

Conciseness5/5

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

The description is dense but every sentence contributes: purpose, indexing warning, per-operation semantics, and guidance about alternatives. The bulleted operation list is easy to scanainer and the final replacement guidance is not padding.

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 tool with multiple operations and nontrivial edge cases, the description is complete: it covers index behavior, units, placeholder quirks, and cross-tool guidance. With an output schema present, not restating return values is acceptable.

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%, so the description must compensate. It explains every operation value, defines geometry parameters in inches, notes that only changed values need to be passed, and states that target_slide_index is 0-based. This makes previously underdocumented parameters actionable.

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 opens with a specific verb and resource: 'Change or remove one existing element' and enumerates the supported element types. The list of operations (delete, clear_text, set_geometry, bring_to_front/send_to_back, move_to_slide) makes the tool's scope unambiguous and distinct from sibling tools like add_shape or manage_text.

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

Usage Guidelines5/5

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

The description explicitly tells the agent how to find shape_index via get_slide_info and warns about 0-based index shifting after deletes/moves. It also names alternatives (populate_placeholder, manage_text) and states the preferred approach for replacing content, giving concrete when-to-use guidance.

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