decksmith
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | Yes | OpenAI API key with image access. Required for image generation. | |
| OPENAI_IMAGE_SIZE | No | Overrides the image size in the [image] section of decksmith.toml. | 1536x1024 |
| OPENAI_IMAGE_MODEL | No | Overrides the image model in the [image] section of decksmith.toml. | gpt-image-2 |
| OPENAI_IMAGE_QUALITY | No | Overrides the image quality in the [image] section of decksmith.toml. | high |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_visual_systemsA | List the visual systems available in this project, marking the default. No API call. |
| initialize_deckA | Create an isolated output workspace from one Markdown file under input/.
|
| submit_deck_planB | Validate and save a proposed slide plan for user review. No API call. |
| approve_planB | Approve an unchanged plan after explicit user review. Requires confirmation APPROVE PLAN. |
| submit_slide_briefsB | Validate and save the full batch of visual briefs. Accepted after plan approval and again after generation: briefs whose content is unchanged keep their existing image, changed ones become pending. No API call. |
| mark_slide_for_regenerationB | Queue one already-generated slide for another attempt with the same brief. No API call. |
| preview_deck_generationC | Write every final prompt and return pending image count plus an approval token. No API call. |
| generate_deck_imagesA | Make paid image API calls for pending slides only. Requires confirmation GENERATE IMAGES. |
| get_deck_statusB | Return the persisted stage, paths, and pending slides for a presentation. No API call. |
| preview_slide_promptC | Validate one brief and return its prompt under a visual system without generating. |
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 10 tools
Each tool targets a distinct pipeline stage (init, plan, approve, briefs, preview, generate, status, regenerate), which makes most boundaries clear. The one overlap is preview_deck_generation vs preview_slide_prompt — one previews all prompts and returns an approval token, the other previews a single brief — but the descriptions distinguish them well enough.
The set follows a consistent verb_noun snake_case pattern throughout: list_visual_systems, initialize_deck, submit_deck_plan, approve_plan, submit_slide_briefs, mark_slide_for_regeneration, preview_deck_generation, generate_deck_images, get_deck_status, preview_slide_prompt. No mixed conventions or stray camelCase.
10 tools is well within the ideal range and each maps to a concrete step in a deck-generation workflow. None appear redundant or trivial filler.
The surface covers the full lifecycle from initialization through plan approval, brief submission, preview, paid generation, status inspection, and per-slide regeneration. Minor gaps remain — no explicit finalize/export of the assembled deck and no cancel/cleanup operation — but core workflows are covered.