Skip to main content
Glama
Sign In
ppt-generator

ppt-generator

by haandol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ingest_slide_edit

Validate, save, render, and lint an add or update slide specification for a presentation project before exporting it to HTML.

Instructions

Ingests an add/update slide spec: validate, save (insert for add), render, lint.

Call AFTER prepare_slide_edit with the same action/slide_index, returned edit_context, and your spec JSON.

Args: project_id: Target project ID (required). action: "add" | "update" (same as prepare). slide_index: 1-based position (same as prepare; use the insertion point for add). spec_json: The slide spec JSON generated by the client. edit_context: Opaque token returned by prepare_slide_edit. color_theme: Color theme ("dark" or "light").

Returns: JSON with design_spec_dir, slide_count, slide_index, slide_html_path, optional lint.

IMPORTANT — Required follow-up: call export_html(project_id=<project_id>).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "action": "<action>",
      "slide_index": "<slide_index>",
      "spec_json": "<spec_json>",
      "edit_context": "<edit_context>"
    },
    "name": "ingest_slide_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYes
spec_jsonYes
project_idYes
color_themeNodark
slide_indexYes
edit_contextYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.2
    • addedInput schema / properties / edit_context
      Added value: +{
+  "title": "Edit Context",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "project_id",
-  "action",
-  "slide_index",
-  "spec_json"
-]New value: +[
+  "project_id",
+  "action",
+  "slide_index",
+  "spec_json",
+  "edit_context"
+]
  2. First observedv0.7.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that state is mutated ('save (insert for add)'), that rendering and linting occur, and that edit_context is an opaque token coupled to prepare_slide_edit. It stops short of covering failure behavior (e.g., what happens if validation or lint fails, whether state is partially written) or idempotency, which is the remaining gap for a write tool.

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?

Front-loaded with the pipeline summary and organized into Args/Returns sections, so scanning is easy. The Returns block is somewhat redundant given a real output schema exists, costing a bit of tightness, but no sentence is filler.

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?

Covers the workflow position (after prepare_slide_edit), the required follow-up (export_html), every parameter's semantics, and the return artifacts. Since an output schema exists, the description need not go deeper on return values, and 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 coverage is 0%, so the description must compensate and it does: it documents all six parameters including enum values absent from the schema ('add' | 'update', 'dark' | 'light'), the 1-based indexing convention, the insertion-point nuance for add, and the provenance of edit_context. This is meaningfully more than the schema provides.

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?

Uses a specific verb-and-resource pairing and enumerates the internal pipeline: validate, save (insert for add), render, lint. It also distinguishes itself from the sibling prepare_slide_edit by positioning itself as the ingestion step that consumes that tool's output.

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 states 'Call AFTER prepare_slide_edit with the same action/slide_index, returned edit_context, and your spec JSON,' giving the ordering precondition and value-carryover rule. It also mandates a follow-up ('call export_html'), so the agent knows the next step even though no when-not exclusions are given.

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