KitchenSink4PPT

Overview Schema Source Related Servers Discussions Admin

Get Presentation View

get_presentation_view

Read-only

Get a markdown outline of a deck with stable anchors for slides, shapes, tables, and notes, enabling targeted edits by referencing those anchors.

Instructions

The anchored markdown projection of a deck, THE cheap way to read it: slide headers with durable [s:id] anchors, one block per shape with a stable [a:hex] anchor, tables as pipe tables with t:hex:rNcN cell addresses (1-based there; table tools take 0-based row/col), notes as quoted blocks. Feed the anchors to apply_edits. scope: None for all slides, an index, {"slide_id": N}, or a list. detail: "outline", "text" (default), or "full" (geometry too). Budgeted: a deck too large to render whole returns whole slides plus a "page" block giving the omitted count and the offset that continues; limit/offset page in slides. Shape and diagram editing: enable_tools(packs=['graphics']).

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`scope`	No
`detail`	No	text
`offset`	No
`file_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.2.1Sep 9, 2026

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

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.7/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 disclosing stable [s:id] and [a:hex] anchors, 1-based vs 0-based coordinate conventions, notes rendered as quoted blocks, and the budgeted pagination behavior with omitted counts and continuing offsets. No contradiction with annotations.

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?

The description is dense and front-loaded with the core purpose before diving into details. Every sentence adds useful information, though the density and parentheticals make it a little heavy; it is appropriately sized for the number of parameters and conventions it must explain.

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?

The description covers the return format, anchor semantics, scope/detail options, pagination, coordinate system caveat, and how to use the result with apply_edits and enable_tools. With an output schema present and readOnlyHint true, nothing essential is missing for an agent to invoke this tool correctly.

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 carries the full burden for parameters. It defines scope values (None, index, {'slide_id': N}, or list), detail values ('outline', 'text', 'full'), and explains limit/offset pagination in slides. This is substantial meaning beyond the bare schema.

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 opens with a specific verb and resource: 'the anchored markdown projection of a deck,' and explains exactly what the view contains (slide headers, shape blocks, tables, notes). This clearly distinguishes it from metadata-style siblings like get_presentation_info by emphasizing it is the cheap way to read a deck and feed anchors to apply_edits.

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?

The description states it is 'THE cheap way to read' a deck and that anchors should be fed to apply_edits, giving clear context for when to use it. It also explains scope, detail, and pagination options. It does not explicitly name alternatives such as get_text or get_presentation_info, but the usage intent is strongly implied.

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