Skip to main content
Glama
Sign In
KitchenSink4AI

KitchenSink4PPT

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Inspect and Audit Deck

ppt_inspect
Read-onlyIdempotent

Audit PowerPoint decks and report accessibility, layout, font, comment, comparison, stats, theme, and status facts without changing files. Use it to identify issues and fixing calls before edits.

Instructions

Audits and deck-level facts: accessibility, layout checks, font inventory, comment report, deck comparison, statistics, theme, brand, autofit, properties, footer support, masters, export engines, and PowerPoint status. Never changes a file. Slide content reads are ppt_read. Operations, one per line, as name: what it does:

  • audit_accessibility: Audit alt text, table headers, reading order, missing titles and contrast; each finding names the fixing call.

  • check_layout: Check slides for overlap, off-slide shapes, tiny text, contrast and more; findings name the fixing call.

  • font_inventory: List every font in use and where, plus fonts declared where no visible text uses them; run before replace_fonts.

  • comment_report: Report every comment thread by slide, with authors, dates, replies and resolved state, plus a markdown summary.

  • compare_decks: Compare two decks slide by slide (matched by id, title, then position): text, layout, shape and notes changes.

  • deck_statistics: Count slides, words in body and notes, shapes, images, tables and charts, and estimate speaking time.

  • diagnose: Check this environment and, optionally, one file; output leaves out local paths unless verbose=true.

  • extract_brand: Read a deck's theme colors, fonts and most-used literal fills, for apply_brand on another deck.

  • zombie_check: Count running PowerPoint processes to spot one left behind by automation; never ends any.

  • get_theme: Read a master's theme: its 12 color slots and its heading and body fonts.

  • get_autofit_state: Report each text shape's autofit mode and shrink level, to find crowded slides.

  • get_document_properties: Read the deck's document properties (title, author, dates, company and counters).

  • get_footer_support: Check whether a slide's design can show a footer, slide number and date; run before set_footer.

  • list_master_elements: List a master's layouts, placeholders, decoration shapes and backgrounds, with which slides use each layout. More operations follow, in the same format, in the op parameter's description.

Input Schema

NameRequiredDescriptionDefault
opYesThe operation to run: one listed in this tool's description, or one of these, in the same format: - get_export_engines: Report which render engines exist here (PowerPoint or LibreOffice) and what each can export. - live_status: Check whether the user's PowerPoint responds, and which open decks have unsaved changes. - powerpoint_status: Report whether PowerPoint is installed and running, and which decks the user has open.
argsNoThe operation's arguments as an object, including file_path unless the operation names other paths or reads no deck; unknown keys are refused. Slides count from 1 in slide_number and from 0 in slide: the user's slide 2 is slide_number 2 or slide 1. ppt_help lists every argument.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with 'Never changes a file' while adding traits annotations cannot express: zombie_check 'never ends any' process, diagnose omits local paths unless verbose=true, and unknown args keys are refused. It stops short of covering failure modes or how findings are shaped beyond a few hints (comment_report's markdown summary).

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?

It is long, but the length is earned by 17 operations and the format is highly scannable: scope statement first, then one 'name: what it does' line per operation. A few lines pad slightly ('and more', 'in the same format') but nothing is redundant with the schema.

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

Completeness4/5

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

For a 17-operation dispatcher with only two parameters and no output schema, the description gives enough per-operation intent and return hints (counts, findings, markdown summary, theme color slots) to call it correctly. Remaining gaps — error behavior and the precise result shape of audit/check findings — are minor for a read-only tool.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: it spells out what each op argument set means in practice (compare_decks takes two decks, diagnose optionally one file, extract_brand reads fills for apply_brand elsewhere). The 1-based slide_number vs 0-based slide distinction lives in the schema rather than the description, so the description is not carrying that burden itself.

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 opening states the tool's domain (deck-level auditing and read-only facts) and immediately enumerates the operations, so an agent knows exactly what class of work this covers. It explicitly excludes slide-content reads and routes them to ppt_read, making the boundary with the most likely sibling unambiguous despite the awkward 'Audits and deck-level facts' fragment.

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 routing is explicit at both levels: 'Never changes a file. Slide content reads are ppt_read' for the tool as a whole, and per-operation sequencing rules such as 'font_inventory ... run before replace_fonts' and 'get_footer_support ... run before set_footer'. Several operations also state what they are for (autofit state 'to find crowded slides', zombie_check 'to spot one left behind by automation').

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

Deploy Server

Other Tools