Skip to main content
Glama

json_to_pptx

Read-onlyIdempotent

Build an editable PowerPoint (.pptx, base64) from a JSON description of the slides, from freedailypro. Each slide takes title, subtitle, bullets (strings, or {text, bullets:[...]} for sub-bullets; set numbered true for 1. 2. 3.), text (a paragraph or list of paragraphs), table ({header:[...], rows:[[...]]}), image ({data: base64 or data: URI of a PNG, JPEG or GIF, alt: description}) and notes (speaker notes). A slide with only a title (and subtitle) is a cover when it is first or has a subtitle; layout "title" or "content" forces it. With an image the text sits on the left and the picture on the right, keeping its shape; an image alone is centred. Bullets, text and subtitle accept bold, italic, code and links; titles and table cells are plain text. Pictures are never fetched from a URL: send base64, and give each an alt text (a warning says when it is missing). Limits: 200 slides, 40 bullets per slide, tables of 60 rows and 12 columns (a table over 14 rows will run off the slide: warning), pictures 8 MB each and 24 MB in all. Themes clean, dark, corporate, warm, minimal, or brand {color, headingFont, bodyFont, dark}. Returns fileName, base64, slides and warnings; invalid input errors name the field, for example slides[2].bullets[1] must be text.

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": {
      "slides": "<slides>"
    },
    "name": "json_to_pptx"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoA theme made from a brand colour and fonts. Replaces theme.
themeNoBuilt-in look. Default clean. Ignored when brand is given.
titleNoDeck title (file property). Default: the first slide's title.
slidesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations already covering safety (readOnly, idempotent, non-destructive), the description adds rich behavioral detail: hard limits (200 slides, 40 bullets, 60x12 tables, 8MB per image/24MB total), warnings for missing alt text and oversized tables, the rule that pictures are never fetched from URLs, and the error format. This is well beyond what structured fields convey.

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 a single dense paragraph, front-loaded with the core purpose, then limits. Every sentence carries information, but the block of formatting/theme/limit rules could be broken into structure for easier scanning. Still efficient for the amount of content.

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?

For a complex nested-parameter mutation tool with no output schema, the description covers return values (fileName, base64, slides, warnings), error naming (slides[2].bullets[1]), themes, and limits — everything an agent needs to call it 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 coverage is 75%, but the description adds semantics the schema lacks: which fields accept markdown (**bold**, *italic*, `code`, links) versus which are plain text (titles, table cells), image layout rules (text left/image right, lone image centred), and the alt-text warning behavior. These are genuinely useful additions over the 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: 'Build an editable PowerPoint (.pptx, base64) from a JSON description of the slides'. This clearly distinguishes it from siblings like csv_to_pptx or markdown_to_pptx, which take different input formats.

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?

Usage context is clear — it converts JSON slide descriptions to PPTX — and the cover-slide rules ('a slide with only a title... is a cover when it is first or has a subtitle') guide construction. However, it never explicitly names alternatives like csv_to_pptx or markdown_to_pptx or states when-not to use this tool, leaving the routing inference to the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources