Skip to main content
Glama
KitchenSink4AI

KitchenSink4PPT

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

PowerPoint Tables and Charts

ppt_tables
Destructive

Create, fill, merge, resize, style, and import PowerPoint tables, plus create, refill, and format native editable charts, with backup and atomic saves.

Instructions

Tables and charts: create, fill, merge, resize, style and import tables, and create, refill and format charts. Table and chart reads are ppt_read. Row and column addresses are 0-based. Every edit backs the file up first and saves atomically. Operations, one per line, as name: what it does:

  • create_table: Insert a native table at a position in inches, optionally filled from rows of data.

  • set_table_cells: Write many table cells in one save: text, and per-cell bold, size, color and fill.

  • merge_cells: Merge a rectangle of cells (0-based, inclusive); text from covered cells moves to the first cell.

  • unmerge_cells: Split one merged region back into cells; its text stays in the top-left cell.

  • insert_table_rows: Insert empty rows before a 0-based row (at = row count appends).

  • delete_table_rows: Delete rows starting at a 0-based row, with their content.

  • insert_table_cols: Insert empty columns before a 0-based column.

  • delete_table_cols: Delete columns starting at a 0-based column, with their content.

  • format_table_cells: Set borders, fill, margins and vertical alignment on a range of cells; text is left alone.

  • set_column_widths: Set table column widths in inches, for all columns or some.

  • set_row_heights: Set table row heights in inches; rows still grow to fit their text.

  • apply_table_style: Apply one of PowerPoint's built-in table styles by name, with its stripe and header options.

  • import_table: Build or refill a table from a CSV or JSON file.

  • create_chart: Insert a native, editable chart (bar, column, line, pie, scatter or combo) from categories and series.

  • update_chart_data: Replace a chart's data in place, keeping its type and styling; the series count must stay the same.

  • format_chart: Format a chart's titles, legend, number format, gridlines and data labels.

Input Schema

NameRequiredDescriptionDefault
opYesThe operation to run: one of the operations listed in this tool's description.
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.6/5.0
Behavior5/5

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

Adds real behavior beyond the annotations: 'Every edit backs the file up first and saves atomically' discloses the safety/rollback model, and per-op consequences are spelled out (deleted rows/cols take their content, merged text moves to the first cell, series count must stay the same, rows still grow to fit text). That goes well past destructiveHint=true and readOnlyHint=false.

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?

Front-loaded summary plus the addressing convention and the backup/atomic-save guarantee, then a scannable one-line-per-op list. With 16 operations the length is the minimum needed and no sentence is filler.

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 16-op mutation tool with a nested free-form args object and no output schema, the description covers the operation set and cross-references ppt_help for argument detail. It does not describe what a successful call returns or how failures are surfaced, which is the remaining gap.

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 genuine meaning for the free-form args bag: 0-based row/column addressing, inches as the unit, 'at = row count appends', and per-op semantics for each enum value. It does not document individual arg keys, delegating that to ppt_help.

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?

Opens with a specific verb+resource scope (create/fill/merge/resize/style tables and charts) and enumerates all 16 operations with one-line definitions. It explicitly carves out the read side: 'Table and chart reads are ppt_read', so an agent can distinguish this from that sibling without opening either schema.

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?

Explicitly routes reads to ppt_read and points to ppt_help for argument details, and each op line implies when it applies (e.g. unmerge vs merge, update_chart_data vs create_chart). It does not state exclusions against the other write siblings (ppt_edit, ppt_graphics, ppt_design), so the boundary with those is left to inference.

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