Build slides with your AI agent

Why AI-generated decks usually look generated

Ask a general-purpose model to make you a presentation and it will do the one thing it is worst at: invent a visual design. It chooses positions in pixels, picks colours it cannot see, and sets a headline at a size it has no way of measuring. The result is recognisable at a glance — text overhanging its box, four blues that were meant to be one, a chart in default library colours sitting on a branded slide. The model was not bad at writing the deck. It was asked to be an art director with no eyes.

Slideable removes that job from the model entirely. The agent picks a layout from a fixed library of 94 archetypes and fills named slots; it cannot set a coordinate, choose a font size, or invent a colour, because no tool accepts one. Design is the template library’s decision and the Brand Kit’s decision. The agent’s decision is what the slide says.

A model that cannot see the slide should not be choosing where things go on it. It should be choosing what the slide argues.

What the 14 MCP tools actually do

The tool surface is deliberately narrow, and it splits into four jobs. Reading: list_decks, read_deck, list_layouts, list_styles, list_starters and list_assets, so the agent can see what exists and what it is allowed to use before it writes anything. Writing: create_deck, add_slide, rewrite_slide, delete_slide, style_slide, set_deck_background and set_deck_language. And one that most deck integrations do not have at all: review_deck.

review_deck is what makes the loop close. Every layout slot carries a character budget — the length the box was actually drawn for — and every write returns an audit against those budgets. When the audit says a slide overflows, the agent is told which slide and rewrites it shorter before moving on. That is the difference between an agent that produces a deck and an agent that produces a deck that fits.

Which AI clients can connect to Slideable

Any client that speaks MCP over hosted HTTP. The ones we have tested against the live server, each with its own install snippet on the home page, are these:

• Claude — web, desktop and mobile, added under Settings, Connectors, Add custom connector.
• Claude Code — claude mcp add --transport http slideable https://www.slideable.ai/mcp
• Codex CLI — an mcp_servers block in ~/.codex/config.toml, with experimental_use_rmcp_client turned on so it will sign in.
• Cursor — Settings, MCP, add server, or an mcpServers block in ~/.cursor/mcp.json.
• VS Code and Copilot CLI — code --add-mcp with an http server, or copilot mcp add interactively.
• Gemini CLI — an httpUrl entry in ~/.gemini/settings.json. httpUrl and url mean different transports there, and the wrong one fails quietly.
• Anything else that reads an mcpServers block — Zed, Windsurf, Kimi, Grok.

The server is hosted rather than local, and that is a design decision rather than an implementation detail. A local MCP server reads deck files off one machine’s disk, which means the agent can only see decks that particular laptop already has. Signing in over OAuth means the agent sees the library you see, from whichever client you happen to be in.

How several people and several agents work on one deck

Everyone brings their own AI, which means a shared deck can have four agents editing it and no two of them briefed the same way. Slideable handles that the way code handles it. Each agent gets its own name, role and token, so a CEO agent, a Sales agent and an Accountant agent are three collaborators, not three copies of you. Agents claim the slides they are working on, comment on each other's, and ask a person to approve what they should not decide alone. An agent set to need review works on a branch: its changes are proposed rather than applied, and a lead merges them only once the design checks pass. The deck keeps a commit history, so what changed, which agent changed it and why survives the meeting where somebody asks why the number moved.

This is the part that does not show up in a demo and matters most in practice. An agent that can edit a shared deck without review is a liability the first time it confidently rewrites the revenue slide. An agent working on a branch is a colleague who sends a pull request — and you choose, agent by agent, which kind each one is.

What to ask an agent to do first

Start with something that reads rather than writes, because it tells you the connection works and shows you the vocabulary. Ask it to list the slide layouts. You will get the archetypes back by name, which is also the fastest way to learn what the library actually contains. Then ask it to build something small and specific — a five-slide update from a paragraph of notes — and ask it to review the deck afterwards. The audit it reports back is the same one the editor runs.

What not to do is ask for a twenty-slide deck in one instruction and then judge the result. That is the workflow that produces the generated-looking deck, and it is not the model’s fault: you gave it no argument to make, so it made one up.