Skip to main content
Glama

Create or Inspect a Slide

create_slide

Create one presentation slide by picking a form (agenda, chart, grid, etc.) and filling typed fields, or by passing a brief for automatic routing to the appropriate slide layout.

Instructions

Create ONE slide from a structured intent in ONE call: pick a form from the menu and put your content in the typed fields (placed on the slide as given), or pass a brief and let the server route it. Fields tagged (per-form) bind only where the form has that slot — ignored-with-warning elsewhere; see each form's binds in browse_catalog.

FORM MENU: agenda_list: an ordered list of sections/topics to walk through bar_rank_chart: bars comparing magnitudes across categories calendar_grid: events on a real calendar - a week planner (day columns x hour axis) or a month grid with release/event chips (data.events) card_grid: several equal, unordered peer blocks (features, options, pillars) case_story: one named story told as evidence: challenge, action, measured result comparison_matrix: options x criteria grid: data.columns x data.rows cycle_flow: a closed loop of ordered stages where the last feeds the first (recurring process) data_table: a plain factual table of records by fields editorial_split: two side-by-side halves in contrast (before/after, problem/solution) funnel: a quantity narrowing through ordered stages gantt_plan: tasks as bars across named periods on a schedule grid gauge_score: one score on a dial against a scale hero_statement: a statement slide: a cover (typographic/image-led/exec-metadata), a from->to or thesis-quote transition, or a contact or next-steps closing hub_spoke: one central element with several elements connected around it kpi_metrics: a board of headline metric cards; add data.sections (Highlights/Risks/Asks) for a one-slide exec summary / board update / QBR snapshot layer_stack: stacked layers where higher sits on, and depends on, lower linear_flow: ordered process stages read left to right (or inputs to process to outputs) maturity_staircase: ascending levels climbing to a higher state nested_magnitude: nested containment - each level contains the next org_structure: a reporting hierarchy / org tree position_map: items placed by two axes - named 2x2 cells or scatter positions pyramid_hierarchy: a triangle of stacked tiers, foundation to apex ramp_curve: a continuous rising wedge split into phases - effort or value accumulating over time section_divider: a section-break slide: big section number + title; blocks = agenda progress chips (emphasis=primary marks the current section) segment_wheel: a wheel of equal segments around a center - peer categories in the round (composition, not flow) status_dashboard: initiatives/workstreams tracked by status, owner, progress strategic_fork: one origin splitting into two mutually exclusive paths, one recommended swimlane_flow: actor/function lanes by phases, task cells, handoffs across lanes swot: the four-quadrant strengths / weaknesses / opportunities / threats grid system_flow_map: nodes connected by directed arrows that carry the message (data/requests move) takeaway_stack: a few bold conclusions, each with one line of support; optional closing ask timeline_roadmap: milestones/phases laid out along a time axis trend_chart: one or more series plotted over time value_chain: support bands over primary activity columns flowing into a goal arrowhead (how value is created; data.support = the bands) visual_showcase: one dominant screenshot/image with numbered callouts pointing into it waterfall_bridge: a start value bridged to an end value by plus/minus contributions

Exact per-form data shapes: browse_catalog(type=schema, family=) — the generated, always-current JSON Schema + a worked example. (List-shaped forms take blocks: [{"label","sub","detail":[str],"emphasis"}]; structured forms take typed data.)

Escape modes: mode=code (caller-supplied python-pptx in sandbox, $0.05 — use for forms the menu cannot express: calendars, custom diagrams); mode=status (poll a job, free). Image-led asks (photo covers, full-bleed visuals): hero_statement + image_prompt (+$0.05) or image_src.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoPython code defining build(prs). Canvas 13.33×7.5", coords in inches. Pre-imported: Presentation, Inches, Pt, Emu, RGBColor, MSO_ANCHOR, PP_ALIGN. Helpers: add_text_box(slide, left, top, w, h, text, font_size=12, bold=False, color=None), add_box(slide, left, top, w, h, fill_color=None, line_color=None, corner_radius=0.05), add_icon, add_image (src = path or https://); theme_color(name) → RGBColor. add_widget(slide, name, x, y, w, h, params=|content=, theme=THEME) draws board-grade SSG widgets/charts (cards, waterfall, gantt, funnel…) — names via `browse_catalog(type=widgets)`. Use font_size=, not size=; use fill_color=, not fill=. When chrome is supplied, use `build(prs, slide)` — chrome is pre-rendered. Helper signatures: `browse_catalog(type=helpers)`.
dataNofamily-specific payload — see the documented shapes
dateNodate callout (per-form).
formNothe form menu pick (see description) — the routing field
modeNoDefault: structured intent / brief. safe = validate-then-render in ONE call (renders + bills only if faithful; else $0 invalid report with the fix — recommended, no dry_run round-trip). code = python-pptx escape. status = poll.
nameNo
waitNoAI-image slides block ~10-15s; `false` returns a job_id to poll, not block (mode=brief).
briefNoprose fallback / extra context for fills
blocksNolist: [{"label","sub","detail":[str],"emphasis","icon":lucide-name,"metric":{value,label}}]
detailNoResponse verbosity. Default `compact`: status, form/variant, fidelity (verbatim|mixed|ai_completed), warnings[]/errors[] (only when present), urls, cost. `full` adds a debug object (engine internals, verify events, latency buckets).
job_idNoPrevious job ID (for mode=status, or mode=code patching)
metricNo
verifyNomode=code tier. Default `lint`: static geometry linter (overlap/off-canvas/zero-size) + composer content validators — no LLM. `lint+vlm` adds a VLM second-look (~+3s) and makes a blank/contentless render a $0 error, not a billed warning. `off` skips checks.
cautionNoone-line risk / caveat callout (per-form).
contextNoone-line subtitle/standfirst
dry_runNoFree pre-commit check (intent or mode=code), cost:0, no PPTX: status + warnings/errors, plus fidelity_forecast (verbatim|mixed|ai_completed|would_reject) and which fields bind vs get authored. Fix errors, re-call with dry_run=false to render.
imageryNoCover/section-divider imagery: photo (default — curated stock photo, half-bleed), wash (abstract color wash), off (typographic only). Content slides are never photo-decorated.
logo_idNoOptional brand logo (from upload_asset purpose=logo) drawn as chrome on content slides; covers/section breaks stay clean.
stylingNoSubject-informed palette + designed cover on default themes (on by default; the design note names the choice). clean = neutral look. Pinned themes never take it.
subjectNocentral entity for forms that have one — hub label, org root, section #, fork origin, media label (per-form).
variantNopin a specific variant within the form (list them via browse_catalog). Unknown variant -> rejected ($0) with the valid list; set allow_variant_fallback to render the family default instead.
headlineNothe assertion-style slide title
languageNoTarget language (default: en)
takeawayNooptional verdict band (per-form). Put the so-what in the headline; add only for a verdict the title can't carry — not every slide.
theme_idNoOptional theme id from browse_catalog(type=themes). Omit for Default (slideforge_standard).
highlightNoone-line emphasis callout (per-form).
image_srcNohttps URL | asset:<id> for image-bearing forms
imagery_tagNoIndustry bucket for cover/section photos. Omit for the general pool.
min_font_ptNoBinding type floor for prose (exhibit furniture has its own). Type grows to meet it; content that can't fit is a $0 min_font_not_met naming the size needed — allow_truncation renders the fitting subset. Typical: 12.
source_noteNosource / footnote line (per-form).
force_renderNoOn completed_with_errors, pptx_url is null (broken slide). Set true to get it anyway. No cost/status effect.
image_promptNogenerate an image when no image_src (+$0.05)
replacementsNoString replacements on loaded code [{old, new}] (for mode=code with job_id)
variant_policyNoRouted-variant maturity policy: production_safe = if the ROUTED variant is draft/beta, render the family's demo-safe sibling instead (warning names both). Never overrides an explicit variant=. Default best_semantic_match.
include_previewNoInline-preview PAYLOAD only (not execution). Default: default (768px). none omits the inline image and returns just the URLs — it does NOT change sync/async. Use `wait` to control execution.
quality_profileNoThresholds layout.presentation_ready is judged against (executive strictest). Measurement only — never blocks a render or changes cost.
allow_truncationNoBy default, supplying MORE items than a form holds is a blocking error (it would drop your data) — the response names the dropped count + a suggested_split. Set true to render the capacity subset anyway (fidelity=verbatim_truncated, never verbatim). Default false.
form_descriptionNo
allow_fabricationNoBrief mode only: by default a bare brief on a DATA form (kpi/funnel/comparison/…) returns status=would_fabricate at cost:0 rather than INVENT the numbers/entities. Supply the data as typed fields to render verbatim, or set true to let the brief author them (fidelity=ai_completed). Default false.
allow_low_confidenceNoBrief routing only: by default a brief that doesn't match a form clearly returns status=needs_confirmation + candidates at cost:0 (no guessed render). Set true to render the top guess and bill it. Default false.
allow_variant_fallbackNoIf the pinned variant is unknown, render the form's default variant (with a warning) instead of rejecting. Default false.
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds significant behavioral context: cost implications, blocking vs. async modes, dry_run free checks, error handling (e.g., min_font_not_met), and mode-specific behaviors (e.g., code sandbox, status polling). No contradictions with annotations.

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 long but well-structured with clear sections (FORM MENU, escape modes, parameter hints). It front-loads the core action and uses headings to organize dense information. Could be slightly more concise, but the verbosity is justified given the tool's complexity.

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 (41 parameters, many forms, multiple modes) and no output schema, the description is remarkably complete. It covers all important aspects: form selection, parameter usage, behavioral details, cost, error handling, and references to sibling tools for additional info.

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?

Although schema description coverage is high (93%), the description adds crucial meaning beyond schema by detailing the entire form menu (30+ forms with their intents and data shapes) and explaining complex parameters like mode, verify, and allow_fabrication. This is essential for correct invocation.

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 the tool's purpose: 'Create ONE slide from a structured intent in ONE call.' It specifies the two main input methods (form+brief) and escape modes (code, status). It also distinguishes itself from sibling tools like browse_catalog (browsing) and create_deck (multiple slides).

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

Usage Guidelines4/5

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

The description provides guidance on when to use different modes (e.g., mode=code for custom diagrams, dry_run for free validation, wait for async polling). It does not explicitly state when not to use this tool versus alternatives, but given the context, the usage is clear.

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