KitchenSink4PPT

Overview Schema Source Related Servers Score Discussions Admin

list_elements

Read-only

List PowerPoint elements (slides, shapes, placeholders, tables, charts, notes, sections, layouts, masters) with ids and locations to locate edit targets. Scope and paging keep large decks complete.

Instructions

THE multiplex enumerator, one kind per call: slides, shapes, placeholders, tables, charts, images, diagrams (SmartArt frames with their editable nodes), notes, sections, layouts, masters. Returns a flat item list with ids and locations; slide-scoped kinds honor scope (None = all slides, a selector, or a list). count is always the true number found; a deck with more elements than fit the per-call output budget returns a "page" block naming how many were held back and the offset that continues, so nothing goes missing quietly. limit/offset page explicitly, and compact=True returns a fields header plus one array per item, about a third the size on large decks. Use it to find layout names for insert_slide and shape ids for editing. The packs (enable_tools) hold the tools that edit what this lists. For one slide in depth, use get_slide_info; for edit anchors, use get_presentation_view.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	Yes
`limit`	No
`scope`	No
`offset`	No
`compact`	No
`file_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.2.1Sep 9, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "type": "boolean"
+}

addedInput schema / properties / limit

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "type": "integer"
+}

First observedv1.0.0Aug 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by explaining exact output behavior: count is always accurate, paging reports held-back items and continuation offsets, compact mode reduces payload size, and scope handling is defined. There is no contradiction with annotations, and the read-only nature is consistent with the enumerator framing.

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 earns its place: element kinds, return shape, paging/count behavior, compact mode, concrete use cases, and sibling routing. It is front-loaded with the core purpose and does not waste words on restating the name or schema.

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 six-parameter tool with no schema descriptions, the description covers nearly all invocation-relevant behavior and output semantics, and an output schema exists for the rest. It explains paging, scope, compact mode, and when to choose alternatives, making it complete enough for correct selection and invocation.

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?

With 0% schema description coverage, the description compensates strongly: kind enumerates valid values, scope explains None/selector/list, limit/offset are described as explicit paging, and compact is tied to a smaller response format. Only file_path is left to inference, and the exact selector/list syntax for scope is not specified, so it is not quite perfect.

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?

The description names a precise verb and resource: it is 'THE multiplex enumerator' that returns flat item lists for many presentation element kinds. It immediately enumerates the supported kinds and contrasts itself with sibling tools, so an agent can tell it apart from get_slide_info and get_presentation_view without opening schemas.

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?

Usage is explicit: use it to find layout names for insert_slide and shape ids for editing, while get_slide_info and get_presentation_view are named as alternatives for other needs. It also tells the agent that editing tools live in the enable_tools packs, giving clear routing for follow-up actions.

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