KitchenSink4PPT

Overview Schema Source Related Servers Discussions Admin

List Elements

list_elements

Read-only

Enumerate PowerPoint items by kind—slides, shapes, placeholders, layouts, and more—returning ids and locations with scope, paging, and compact output to target elements for editing or insertion.

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

A5/5.0

Behavior5/5

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

Annotations only say readOnlyHint=true and openWorldHint=false; the description adds substantial behavior: one kind per call, slide-scoped kinds and scope semantics, count always being the true count, pagination with a 'page' block so nothing goes missing, and compact=True output behavior. These go well beyond the annotations and schema.

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 long but information-dense; every clause contributes: capability, return shape, scope semantics, pagination guarantees, compact mode, and routing to related tools. It is front-loaded with the core behavior, making the most important disambiguation immediately visible.

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?

Given 6 parameters, 0% schema coverage, an output schema, and safe read-only annotations, the description covers all critical decision points: what kinds exist, how scope works, how paging/limits behave, how to reduce payload size, and which sibling tools to use instead. Nothing an agent needs to invoke it correctly is missing.

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 kind by enumerating valid values, defines scope with 'None = all slides, a selector, or a list', and describes limit/offset and compact=True behavior. Only file_path is not described, but it is obvious from the required parameter name and the tool's purpose.

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: 'THE multiplex enumerator, one kind per call: slides, shapes, placeholders, tables, charts, images, diagrams...' It enumerates the kinds it handles and states what it returns ('flat item list with ids and locations'). This clearly distinguishes it from siblings like get_slide_info and get_presentation_view.

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?

Explicitly says when to use it: 'Use it to find layout names for insert_slide and shape ids for editing.' It also routes to alternatives: 'For one slide in depth, use get_slide_info; for edit anchors, use get_presentation_view.' This is exactly the when/alternative guidance an agent needs.

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