InstaDeck
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INSTADECK_HOME | No | Where decks, brand kits and assets live for the local server. | ~/InstaDeck |
| INSTADECK_CHROME | No | Path to the browser executable for the local server. | found automatically |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_design_guideA | How to build an InstaDeck: workflow, layouts with their zones, block types, motion presets, design system rules, fonts, pitch story beats and the design and storytelling principles behind them. Call it before creating or restyling a deck. |
| add_assetA | Stores a logo, image, photo or font file so slides and brand kits can use it by asset id. Images: PNG, JPEG, WebP, GIF, SVG. Fonts: WOFF2, WOFF, TTF, OTF. Up to 15 MB. |
| list_assetsB | Lists stored logos, images and fonts with their ids. |
| extract_brand_colorsA | Reads the colors of a logo or brand image and returns candidates with their share and whether they are neutral (white, black, gray). You decide which one is the brand color. The hosted connector reads SVG only, for PNG or JPEG logos read the colors from the image yourself. |
| create_brand_kitB | Saves a brand: primary and secondary colors, dark and light, fonts, logos and tone. Decks created with the brand kit take its colors and fonts. |
| suggest_brand_systemA | Turns a primary color and a mood into a coherent, readable brand system: palette with verified contrast, a font pair, type scale, corner radius, tempo and a starting motion intensity. Returns brand_kit (pass to create_brand_kit with a name and logos) and design and motion (pass to create_deck). Every change to your colors is listed in adjustments. |
| get_brand_kitC | Returns a brand kit by id. |
| list_brand_kitsB | Lists saved brand kits. |
| get_exampleA | Returns a proven example deck. Without id it lists the examples with purpose, audience and layouts. With id it returns the full deck in the shape create_deck takes (slides, design, motion) and why it works. Read the example closest to the brief before choosing layouts, then keep its structure, rhythm and text lengths and replace all content. |
| create_deckB | Creates a deck with all its slides in one call and renders it as a presentation file with animations. Returns the deck id, revision, findings (validation and measured overflow) and previews. Nothing is saved when the slides have errors. |
| get_deckA | Returns the full deck: brief, design, motion and every slide with its blocks, plus the revision to pass to apply_ops. |
| get_deck_viewA | Used by the InstaDeck view in the chat to render a deck. You never need to call it: create_deck, apply_ops and get_deck already show the deck. |
| list_decksB | Lists decks with title, company, number of slides and last change. |
| apply_opsA | The only way to change a deck. Applies operations in order (add, update, remove or move slides, set design, motion, title, brief, apply a brand kit). All operations succeed or none is saved. Fails when expected_revision is not the current revision. |
| validate_deckB | Checks a deck: structure, data, contrast, text length, motion budget and visual rhythm. The local server also measures text that overflows its space in a browser, on the hosted connector the deck view reports overflow when it renders. |
| render_previewA | PNG images of slides in their final state (all steps revealed). Use it to check the design visually. |
| export_deckA | Exports the deck as a presentation HTML file (animations, one file, opens in any browser), a PDF with selectable text, or a PowerPoint file (editable text, native charts and tables, speaker notes, no animations). |
| get_historyA | Lists the revisions of a deck with author, summary and operations. |
| revert_deckB | Restores an earlier revision as a new revision. History is kept. |
| delete_deckA | Deletes the deck folder with its history, presentation and PDF. Cannot be undone. Ask the user first and pass confirm: true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| create_pitch_deck | Start a branded pitch deck from a company and a topic |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| workflow | Step by step workflow for building a deck |
| layouts | Slide layouts with their zones and accepted blocks |
| blocks | Block types, highlighting, text limits and click reveals |
| motion | Motion language: intensity, presets, your own keyframe vocabulary, shared transitions, tempos and what is measured |
| fonts | Curated Google Fonts with weights and character |
| pitch | Pitch deck story beats and guidance |
| design-principles | Design principles behind the system |
| storytelling-principles | Storytelling principles for structuring the deck |
| motion-principles | Why and when things move: perception research behind the motion rules |
| examples | Proven example decks: purpose, audience and layouts |
| capabilities | What InstaDeck can do and the status of each capability |
| deck-view | Plays an InstaDeck presentation in the chat |
| Seed round pitch | A full example deck in the shape create_deck takes, with why it works |
| Enterprise sales deck | A full example deck in the shape create_deck takes, with why it works |
| Product launch | A full example deck in the shape create_deck takes, with why it works |
| Quarterly board update | A full example deck in the shape create_deck takes, with why it works |
| Consumer app launch | A full example deck in the shape create_deck takes, with why it works |
TDQS
Scored across 20 tools
Most tools have clearly distinct purposes across assets, brand kits, decks, and history. Minor overlap exists between get_deck and get_deck_view (the latter explicitly says you never need it), and between validate_deck and the built-in validation reported by create_deck, but the descriptions do clarify these.
Every tool follows a predictable snake_case verb_noun pattern: get_design_guide, add_asset, create_brand_kit, list_decks, apply_ops, render_preview, etc. The convention is uniform across all 20 tools with no mixed casing or vague verbs.
20 tools is on the heavier side but the server spans several subdomains (assets, brand kits, decks, revision history), so most tools earn their place. A few (get_deck_view, extract_brand_colors) could arguably be folded in, but overall it's reasonably scoped.
Deck lifecycle is thorough (create, get, list, apply_ops for mutation, validate, render, export, history, revert, delete), and brand kits have create/get/list/suggest. Minor gaps: no delete or update for assets and brand kits, which agents may need to clean up.