slideshot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PUPPETEER_SKIP_DOWNLOAD | No | Set to 'true' to skip bundled-Chromium download | |
| PUPPETEER_EXECUTABLE_PATH | No | Path to Chromium binary |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discover_themesA | MANDATORY first step — all other tools REJECT until this is called. Returns themes, orientation presets, token-usage modes, and output formats. Use ONLY the native selector prompts from the "ask" array — DO NOT render themes as a separate markdown list. DO NOT ask how many slides (you decide based on topic). After user picks options, show a data outline of proposed slides and WAIT for confirmation before calling create_slides. |
| create_slidesA | Create slides. IMPORTANT: Use mode=default unless the user explicitly chose token_saver. mode=default = AI writes full HTML (best quality). mode=token_saver = AI sends JSON, server uses basic templates. REQUIRES discover_themes first AND user must have confirmed the data outline. After this tool saves the HTML, you MUST show the htmlPath as a code preview artifact. Then STOP and ask the user to confirm. DO NOT call render_slides until the user explicitly confirms. |
| render_slidesA | Final render to PDF/WebP/PNG/PPTX. Accepts html string OR htmlPath. Supports width, height, selector, scale, webpQuality, orientation, pptxMode, pptxFilename, slideRange. NEVER call render_slides in the same turn as create_slides. When the user provides an existing HTML file path, pass it as htmlPath and call this tool directly — no discover_themes or create_slides needed. For the full slide-creation workflow, REQUIRES both discover_themes AND create_slides first, and ONLY call AFTER user confirms the preview. Returns file paths on disk. |
| list_themesA | Idempotent read-only listing of all available themes (8+). Unlike discover_themes, this does NOT start a slide-creation workflow — call it any time the user asks "what themes are there?" mid-conversation. Returns the same tiered theme catalog (primary/secondary). Models MUST present every theme returned, never truncate. |
| edit_slidesA | Token-efficient partial edits on a previously-generated HTML deck. Use this INSTEAD of regenerating the whole deck for small changes — it saves 60-90% tokens vs a full rewrite. Operations: replace_slide (swap one slide block by 1-indexed slideIndex), patch_css (append CSS rules to ), swap_token (replace a CSS variable's value, e.g. {"--coral": "#FF0000"}), patch_class (add/remove a class on a specific slide, e.g. {"add": "dark"}). Reads from cache or htmlPath; saves the updated HTML and returns the new htmlPath. After editing, show the htmlPath as a preview artifact and STOP — do NOT call render_slides until the user confirms. |
| health_checkA | Verify Puppeteer/Chromium can launch. Use when render fails. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
All tools have distinct responsibilities, but discover_themes and list_themes both surface the theme catalog and could be confused if an agent only glances at names; the descriptions do clarify that one is a mandatory workflow bootstrap and the other is a read-only listing. create_slides, edit_slides, and render_slides are otherwise cleanly separated by operation.
Most names follow the verb_noun snake_case pattern consistently: discover_themes, create_slides, render_slides, list_themes, edit_slides. health_check breaks the pattern slightly by being a noun phrase rather than a verb-first command, though it remains simple and readable.
Six tools is a well-scoped count for a slide-generation and rendering server: health check, theme discovery, theme listing, create, render, and edit. Each tool has a clear role, and none feels like unnecessary surface area.
The core lifecycle is covered: discover themes, create slides, render to output formats, and apply token-efficient partial edits. Minor gaps exist, like no explicit slide deletion or no tool to inspect a previously generated deck's structure, but most workflows can be completed without them.