MCP | 9 min read | 2026-04-25 | Updated 2026-04-26 | By Variant Team

How AI Agents Can Create, Preview, and Edit Slide Decks

A practical look at the agent loop for slides — create, preview, inspect, edit, export — with Variant's MCP tools as the concrete example.

Author: Variant Team. Variant is built by a small team working on HTML-native presentation tools, MCP workflows, and agent-editable decks.

An AI agent slide deck workflow works when the agent can do four things in sequence: generate the slides, see what it just made, change specific parts, and export the result. Most "AI presentation" tools only do step one, which is why the output often feels generated rather than designed.

This piece is about the loop that actually works for coding agents like Claude Code, Cursor, and Codex. We'll walk through why preview matters more than people expect, what each step in the loop actually does, and how Variant's MCP server implements it as a concrete example.

#Quick answer

A useful AI agent slide deck loop has five stages: create, preview, inspect, edit, export. The preview step is the one most tools skip and the one that makes everything else work. Without it, the agent is editing blind and you end up rewriting whole slides to fix small mistakes.

Variant exposes this loop to Claude Code over MCP. The agent calls deck.create to generate, slide.preview to render an image of any slide, slide.get or selection.get to read structure, slide.edit or slides.batchUpdate to change things, and deck.export to ship to HTML, PDF, PPTX, or JSON.

#Why "generate and pray" stops working fast

The first generation of AI slide tools treated the deck as a one-shot output. Type a prompt, get a deck, done. If something is wrong you regenerate the whole slide, or sometimes the whole deck, and hope the next roll is better.

That works for throwaway content. It falls apart the moment you care about a specific number, a specific brand color, the way a chart is labeled, or the order of bullets on slide seven. You don't want a new slide. You want *that* slide, with one thing changed and the rest left alone.

Coding agents already know how to handle this for code. They read a file, run it, look at the output, and patch the part that's wrong. Slides need the same treatment. The deck is the artifact, the preview is the test, and edits are diffs.

#The agent loop for slides

Here's the loop, in text:

        ┌──────────┐
        │  CREATE  │  generate initial deck from prompt + context
        └────┬─────┘
             │
             ▼
        ┌──────────┐
        │ PREVIEW  │  render slide → image the agent can actually see
        └────┬─────┘
             │
             ▼
        ┌──────────┐
        │ INSPECT  │  read structure: which element, what styles, what text
        └────┬─────┘
             │
             ▼
        ┌──────────┐
   ┌───►│   EDIT   │  targeted change: one element, one slide, one batch
   │    └────┬─────┘
   │         │
   │         ▼
   │    ┌──────────┐
   └────┤ PREVIEW  │  did the change look right? if no, loop again
        └────┬─────┘
             │
             ▼
        ┌──────────┐
        │  EXPORT  │  HTML, PDF, PPTX, or JSON
        └──────────┘

The dotted line back to preview is the part that matters. Each edit is followed by a render so the agent sees what changed, the same way a coding agent runs tests after a patch.

#Step 1: create

Creation is the easiest step, conceptually. The agent gets a prompt, ideally with some context like a doc, transcript, spec, or existing deck, and produces slides.

In Variant, this is deck.create. The agent passes a brief and gets back a deck of HTML slides. Every slide is plain HTML and CSS. No proprietary slide format, no binary blob, no XML soup. That choice matters for the rest of the loop, because anything the agent can read and write as HTML, it can edit precisely later.

A small example prompt the agent might run:

Create a 6-slide deck for a Series A pitch. Title, problem, solution, traction (numbers TBD), team, ask. Use a clean dark theme with a single accent color.

That gets back a real deck the agent can immediately preview, inspect, and refine.

#Step 2: preview (the part everyone underestimates)

Slides are visual. Text-only descriptions of a slide — "a heading, two columns, a chart on the right" — lose almost everything that matters. Whether the chart overlaps the heading. Whether the contrast is readable. Whether the spacing looks balanced. Whether the title actually fits.

This is why a slide.preview tool matters so much for agent-driven slide work. The agent renders the slide to an image, looks at the image, and reasons about the visual result instead of guessing.

Variant's slide.preview tool returns the rendered slide as an image the agent can read directly. After every meaningful edit, the agent can render again and compare. If the chart is too small, it knows. If the title wraps awkwardly, it knows. If the new background eats the body text, it sees it.

Without this step, agents write code changes that look right in the markup but break visually. With it, the agent does what a designer does: make a change, look at it, adjust.

#Step 3: inspect

Editing well requires knowing what's there. The agent needs to answer questions like: which element holds the headline, what font size is the body text, what's the current accent color, which slides are 16:9 and which got resized.

Variant gives the agent inspection tools that read the deck's structure: the slide list, the elements on a given slide, the user's current selection if they've clicked something on the canvas. That last one is the bridge between the human and the agent. You click a chart, type "make this taller and switch to bar instead of pie," and the agent already knows which element you mean because it can read the selection.

#Step 4: edit

Editing is where the AI agent presentation story gets interesting, because there are several scopes the agent might want:

Scope	When to use it	Variant MCP tool
One element on one slide	Fix a typo, swap a color, resize a single chart	`slide.edit`
Multiple slides at once	Apply a theme change, renumber, replace a recurring logo	`slides.batchUpdate`
Add or replace a slide	Insert a new section, redo a single slide cleanly	`slides.batchUpdate`
Restore a prior version	Undo a bad run, branch from an earlier state	`deck.version.restore`

The point is that the agent doesn't have to regenerate the whole deck to fix one word. It edits the actual slide. That's what makes the deck feel like a working document instead of a disposable render.

A real workflow:

User: "the third slide's headline should say 'monthly active' not 'daily active.'"
Agent calls slide.get on slide 3, finds the headline element.
Agent calls slide.edit to change just the text content.
Agent calls slide.preview to confirm.
Done. Two seconds. No regeneration.

Compare that to a generate-and-pray tool, where the same fix means re-rolling the slide and hoping nothing else changes.

#Step 5: export

Once the deck is right, the agent ships it. Variant's deck.export supports four formats, and the choice matters more than people think:

Format	Best for	Notes
HTML	Sharing a link, embedding, hosting anywhere	Single self-contained file. The canonical format.
PDF	Email attachments, print, fixed-layout sharing	Loses interactivity but universal.
PPTX	Handing off to someone in PowerPoint	Useful for collaboration with non-technical reviewers.
JSON	Programmatic use, archiving, migrating decks	The structured representation of the deck.

HTML is the strongest format because the deck is already HTML. The export is one self-contained file you can open in any browser, drop on any static host, and inspect with view-source. No runtime dependency on the slide tool that made it. That's a big deal if you want your decks to outlive the platform.

#Why this works for coding agents specifically

Claude Code, Cursor, Codex, and the rest of the vibe coding crowd are already wired for this loop. They read files, write files, run things, and check output. A code-native slide deck plugs into that wiring without translation.

A few reasons the fit is good:

Slides are HTML. The agent already knows HTML. No new DSL to learn, no escape hatches needed.
Preview returns an image. Multimodal agents can look at it the same way they'd look at a screenshot of a UI bug.
Edits are scoped. slide.edit is closer to a small patch than a whole-file rewrite. Faster, safer, cheaper.
Versioning is built in. deck.versions.list and deck.version.restore give the agent (and you) an undo button at any point in the loop.
MCP setup is standard. OAuth or scoped bearer tokens. The agent connects once and gets access to all 18 of Variant's MCP tools.

#A worked example: turning a doc into a deck, then fixing the parts that are wrong

Imagine you've got a product spec and you want a 10-slide internal review deck by tomorrow morning. With an AI agent slide deck workflow, this looks roughly like:

Create. You point the agent at the spec and say "make a 10-slide deck for the Friday review, use our brand colors, leave the metrics slide blank for now." Agent calls deck.create. Deck appears in Variant.
Preview. Agent calls slide.preview for each slide. Notices slide 4's chart is overflowing the frame.
Inspect. Agent calls slide.get on slide 4, sees the chart container is fixed at the wrong height.
Edit. Agent calls slide.edit to set the container height to fit-content. Re-previews. Looks right.
You step in. You open Variant, click the title on slide 1, type "make this 20% bigger and add a subtitle that says 'Internal review, April 2026'." The agent reads your selection, edits the right element, previews. Done.
Drop into code. You want to tweak a specific gradient by hand. You switch to the code tab, edit the CSS, and the canvas updates. Canvas and code stay in sync.
Export. Agent calls deck.export to HTML for the link you'll share, and PPTX for the one VP who insists on PowerPoint.

That whole flow is a handful of MCP calls. None of it is "regenerate and hope."

#Setting it up

If you're already using Claude Code, hooking Variant in as an MCP presentation server takes a couple of minutes. You authenticate with OAuth or a scoped bearer token, point Claude Code at the MCP endpoint, and the 18 tools show up. From there, asking Claude Code to "make me a deck about X" runs through the create → preview → edit loop on its own.

#FAQ

What's the difference between an AI agent slide deck and an AI-generated slide deck? A generated deck is a one-shot output. An agent deck is the result of a loop: the agent generates, looks at the output, makes targeted edits, and iterates. The second one ends up usable.

Why does the preview step matter so much? Slides are visual. Without rendering each slide back to an image the agent can see, the agent is editing markup blind. Preview is the equivalent of running tests after a code change.

Can I edit a slide by hand after the agent makes it? Yes. In Variant, every slide is HTML and CSS. You can edit visually on the canvas, drop into a code tab, or have the agent make changes. All three views stay in sync.

Which export format should I use? HTML if you want a single self-contained file you can host anywhere and inspect later. PDF for email and print. PPTX if you're handing off to someone in PowerPoint. JSON if you're doing something programmatic.

Does this work with Cursor or Codex, or only Claude Code? Anything that speaks MCP can connect. Variant's MCP server is the integration point, not the specific agent.

Can the agent undo a bad change? Yes. deck.versions.list and deck.version.restore give the agent (and you) version history at any point in the loop.

#A useful first loop

If you want to see the create → preview → inspect → edit → export loop in action, try it on a small deck you already understand. Hook a presentation MCP server into Claude Code and ask the agent to build something specific. The first time you watch it preview a slide, notice a problem, and fix it without regenerating, the rest of the workflow makes sense.