Documentation

Generate, verify, and export decks from the web app, from Claude via MCP, or from any system via REST.

Overview

Agentic Slides is a canvas slide editor where clean HTML is the single source of truth and an LLM edits one element at a time. Every slide lives on a fixed canvas (16:9, 1280×720 by default), is serialized deterministically, and is checked against a layout spec before it ships.

There are three ways to drive it. The REST and MCP doors expose the same service layer.

Web app

Generate and edit decks in the browser at slides.product-masterclass.com.

MCP

Call it from Claude Desktop or Claude Code. See MCP tools.

REST

Call it from any language over HTTP. See the REST API explorer.

Local (stdio)

Run the MCP server locally, key-free, for development.

Quickstart

1. In the app

  1. Create a free account at slides.product-masterclass.com/auth.
  2. Click New deck and describe what you want, e.g. "a brand-conformant 10-slide deck pitching our developer onboarding program, one idea per slide".
  3. Render a slide to confirm the layout holds, then export to PDF, PNG, or reveal.js.

2. Over REST

Mint a key in Account → API keys, then generate a deck. The same call in three languages:

cURL

curl https://slides.product-masterclass.com/v1/decks/generate \
  -H "x-api-key: $AGENTIC_SLIDES_KEY" \
  -H "content-type: application/json" \
  -d '{ "prompt": "a 6-slide deck on customer onboarding" }'
# → 201 Created, body is the deck HTML (text/html)

Python

import os, requests

res = requests.post(
    "https://slides.product-masterclass.com/v1/decks/generate",
    headers={"x-api-key": os.environ["AGENTIC_SLIDES_KEY"]},
    json={"prompt": "a 6-slide deck on customer onboarding"},
)
res.raise_for_status()
deck_html = res.text   # the deck, as canonical HTML

JavaScript (Node 18+)

const res = await fetch(
  "https://slides.product-masterclass.com/v1/decks/generate",
  {
    method: "POST",
    headers: {
      "x-api-key": process.env.AGENTIC_SLIDES_KEY,
      "content-type": "application/json",
    },
    body: JSON.stringify({ prompt: "a 6-slide deck on customer onboarding" }),
  },
);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const deckHtml = await res.text();

Then render slide 1 to verify, and export:

# Render returns image/png
curl "https://slides.product-masterclass.com/v1/decks/$DECK_ID/render/$SLIDE_ID" \
  -H "x-api-key: $AGENTIC_SLIDES_KEY" --output slide-1.png

# Export the whole deck to PDF
curl https://slides.product-masterclass.com/v1/decks/$DECK_ID/export \
  -H "x-api-key: $AGENTIC_SLIDES_KEY" -H "content-type: application/json" \
  -d '{ "deckHtml": "<...>", "format": "pdf" }' --output deck.pdf

3. Over MCP (Claude)

Add the remote MCP server with your key, then prompt naturally:

Use the Agentic Slides MCP tools. Call get_spec first, then generate_deck with a one-idea-per-slide prompt. Render slide 1 with render_slide so I can confirm the layout, then export_deck as PDF.

Full setup: MCP tools. Authentication details: Authentication.

Core concepts

HTML is the source of truth

Decks are stored and returned as clean, deterministically-serialized HTML. The same model always serializes to the same bytes, so decks diff cleanly and are versionable in Git. Most write endpoints take a deckHtml string and return the updated deckHtml, so you thread the deck through calls rather than holding server state.

The verification loop

Rather than trusting the LLM to emit perfect HTML, the service renders a slide to an image and measures it. The model can see overflow or off-brand styling and correct the exact element before export. That is what render_slide / GET …/render/{sid} are for.

Canvas & formats

Slides live on a fixed canvas. Pick a preset or supply a custom width+height.

FormatSize (px)Aspect
widescreen (default)1280 × 72016:9
square1080 × 10801:1
portrait1080 × 13504:5
story1080 × 19209:16

Tenancy & API keys

Every API key maps to a tenant. Stored decks and brand profiles are scoped to that tenant. Most calls infer the tenant from your key; a few accept an explicit tenantId. See Authentication.

Brands & profiles

A brand profile locks colors and fonts. Generated and re-themed decks obey the tenant's active profile automatically; apply_brand re-themes an existing deck. Manage profiles via the /v1/brand endpoints or the brand MCP tools.

Deck & slide model

When you need to reason about the structure behind the HTML, this is the shape the engine round-trips to:

Deck {
  id: string
  title: string
  canvas: { width: number, height: number }   // logical CSS px, default 1280×720
  theme: Record<string, string>                // CSS custom properties, e.g. "--accent": "#0ebeaa"
  slides: Slide[]
}

Slide {
  id: string            // stable; used as {sid} and in reorder order[]
  background: string    // CSS background value
  html: string          // inner HTML (no <section> wrapper)
  className?: string
}

Every top-level editable node in a slide's html carries a data-el-id (e.g. el-title, el-subtitle). These ids are stable across edits and are how you scope an AI edit to specific elements (the elementIds parameter). Fetch the authoritative rules any time with GET /v1/spec or the get_spec tool.

Heads up: the REST render response is a PNG and most write responses are text/html (the deck), not JSON. Only list/spec/brand/edit endpoints return JSON. Each operation's exact content type is in the REST API explorer.