ChatPPT

Overview Schema Source Related Servers Discussions Admin

element_update

Updates positioning, sizing, text, colors, typography, stroke, and alignment for one or multiple slide elements in a single batch call, so you can revise a PowerPoint slide's layout and styling without editing each element individually.

Instructions

Update positioning, sizing, text, fill, typography, stroke, or alignment for one or multiple elements on a slide in batch.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "deckId": "<deckId>",
      "slideId": "<slideId>",
      "updates": "<updates>"
    },
    "name": "element_update"
  }
}

Input Schema

Name	Required	Description
`deckId`	Yes	Stable ID of the presentation deck
`slideId`	Yes	Stable ID of the slide
`updates`	Yes	Array of element updates

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 13, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about partial-update semantics (only elementId is required, so omitted properties presumably stay untouched), whether a batch is atomic, what happens on an unknown elementId, or whether changes require specific permissions. It discloses only the set of mutable fields, which is essentially a restatement of the schema.

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?

A single front-loaded sentence with the verb and resource first and the mutable property list trailing. It is efficient, though the seven-item enumeration is somewhat redundant with the schema and could be compressed.

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

Completeness3/5

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

For a mutation tool with no annotations and no output schema, the definition covers what can be changed but omits the behavioral contract an agent needs: partial-update defaults, batch atomicity, failure behavior, and any confirmation of what is returned. The rich nested schema compensates for field-level detail but not for these semantics.

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

Parameters3/5

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

Schema description coverage is 100% and every nested update field (x/y/w/h in inches, fontSize in points, hex colors) is documented in the schema itself. The description's property-group listing adds only navigational value, matching the baseline 3 when the schema does the heavy lifting.

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

Purpose4/5

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

The description gives a specific verb (update) and resource (elements on a slide) and enumerates the editable property groups, so an agent can distinguish it from element_create, element_delete, and element_reorder by intent. It stops short of explicitly naming a sibling it is not, but the scope is unambiguous.

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

Usage Guidelines3/5

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

Usage is only implied: the mention of 'one or multiple elements ... in batch' hints that batching is the intended mode, but there is no guidance on when to prefer this over element_create or element_reorder, and no stated prerequisites such as needing an existing elementId from element_list.

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