KitchenSink4PPT

Overview Schema Source Related Servers Score Discussions Admin

get_presentation_view

Read-only

Read a PowerPoint deck as markdown with stable anchors for slides, shapes, tables, and notes, then use those anchors to apply targeted edits.

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?

Beyond the readOnlyHint annotation, it discloses the output format ('slide headers with durable anchors', 'pipe tables', 'quoted blocks'), cell address conventions, budgeted rendering behavior, and how to enable graphics editing. This gives an agent a rich, accurate model of what will happen when the tool is called.

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, followed by structured details for output, scope, detail, and pagination. It is slightly run-on, but every clause contributes meaningful behavior, so the length is justified despite some stylistic informality.

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 output shape, anchor semantics, all parameter families, budgeted behavior, and the relationship to editing workflows. An output schema exists for return values, and readOnlyHint handles safety, so nothing critical is left unexplained 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?

With 0% schema description coverage, the description takes on full parameter documentation. It explains scope (None, index, slide_id object, or list), detail levels ('outline', 'text', 'full'), and limit/offset pagination semantics. The 1-based table addresses vs 0-based table-tool convention also clarifies offset-related behavior.

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 clearly identifies the tool as 'anchored markdown projection of a deck' and 'THE cheap way to read it', with a specific verb and resource. It conveys the core purpose of reading a presentation efficiently and distinguishes it from edit-oriented siblings by mentioning stable anchors for 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 provides strong usage context: scope values, detail modes, budgeted pagination, and how to feed anchors to apply_edits. It does not explicitly name alternative tools or state when not to use this tool, but the 'cheap way to read it' phrasing and detailed invocation options make intended usage clear.

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