Skip to main content
Glama

Create Multi-Slide Deck

create_deck

Create a themed PowerPoint deck from slide intents in one call, with dry-run validation and strict policy gating for quality control.

Instructions

Create a WHOLE deck in one call: slides is a list of create_slide intents (same form menu + data shapes — see create_slide). Slides fill in parallel and merge into one themed PPTX with page numbers. Include furniture: a hero_statement cover, section_divider breaks, and a closing (hero_statement variant=contact_closing via blocks-free slots).

Also: mode=assemble merges existing slide job_ids as-rendered (free; theme_id does NOT re-theme them — render with create_deck(slides=[…], theme_id=…) for a unified theme); mode=fork clones a deck (free). Polling: deck_id == job_id — manage_account(action=job, job_id=).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoDefault render. assemble/fork are free deck plumbing.
nameNo
titleNoDeck title (PowerPoint metadata)
slidesNoeach item is a create_slide intent (same form menu, typed fields, and data shapes as create_slide).
deck_idNoExisting deck ID (for mode=fork, or mode=render to update)
dry_runNoDeck-level free pre-flight (cost:0, NO render/PPTX): returns a per-slide validation manifest [{i, form, fidelity_forecast, status, errors}] so you can fix bad slides before spending. A deck is one artifact, so validation is all-or-nothing — put dry_run here, not on individual slides. Resend without dry_run to render.
job_idsNoSlide job IDs to merge (for mode=assemble)
logo_idNoOptional brand logo (from upload_asset purpose=logo) applied as chrome to every content slide in the deck.
stylingNoDeck-level topical-design switch, inherited by every slide (a slide-level styling wins). See create_slide.styling.
languageNoTarget language
theme_idNo
force_renderNoIf any slide is completed_with_errors, deck pptx_url is null. Set true to get it anyway; complete slides stay downloadable via their per-slide job_id either way. No cost/status effect.
allow_partialNoNon-regret default: if any slide fails, the deck is NOT billed (cost:0) and pptx withheld — the response carries repair_actions (assemble the completed children, free). Set true to render + bill the completed slides and get the partial deck. Default false.
strict_policyNoOptional CI-style gate for automated report pipelines. dry_run returns policy_result; render returns rejected/cost:0 if the policy fails.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

A annotations do not contradict the description. The description discloses key behaviors such as slides filling in parallel, polling via deck_id=job_id, cost implications (dry_run free, allow_partial billing), and policy gates. This goes beyond annotations to aid correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise given the number of parameters and complexity. It is front-loaded with the main purpose and then logically covers modes, polling, and edge-case parameters. Minor redundancy could be trimmed but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (14 parameters, nested objects, multiple modes, no output schema), the description provides comprehensive guidance on inputs, behavior, and error handling. It covers validation, cost, polling, and policy gates, making it complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 86%, the description adds significant value by explaining the relationship between slides and create_slide, the meaning of modes, dry_run's return value, and the effect of force_render, allow_partial, and strict_policy. This helps the agent understand parameter usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a WHOLE deck in one call' and details the slides parameter and modes. It distinguishes itself from siblings like create_slide by explaining that slides are a list of create_slide intents. The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use each mode (render, assemble, fork) and when to use dry_run. It also references create_slide for individual slides and explains that assemble and fork are free. This helps the agent choose between tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smartdatabrokers/slideforge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server