Skip to main content
Glama

Create or Inspect a Slide

create_slide

Create one PowerPoint slide (.pptx, native, editable) 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.

BLOCKED ($0)? If an error has can_autofix:true, merge its patch into the args at patch_target. Unchanged retries repeat the block. New form: browse_catalog(type=schema) first.

FORM MENU: agenda_list: an ordered list of sections/topics or learning objectives to walk through bar_rank_chart: bars comparing magnitudes across categories calendar_grid: events on a real calendar - week planner (day x hour) or month grid with event chips (data.events) card_grid: several equal, unordered peer blocks (features, options, pillars, a concept's defined parts, rules/guidelines/common mistakes) 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: contrast (before/after, problem/solution) or copy/numbered steps beside a picture (image_src) exercise_prompt: an exercise/practice/discussion prompt: instruction + hints; optional problem items with blank answer boxes 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: covers (typographic/image/exec), from->to/thesis-quote transitions, statement/contact/next-steps closings; supporting points -> takeaway_stack, contacts -> data.contacts, next steps -> data.next_steps hub_spoke: one central element with several elements connected around it image_story: a picture shown WHOLE (uncropped) + prose, or a 1-6 picture/placeholder gallery (data.images); points beside a picture -> editorial_split kpi_metrics: a metrics dashboard: headline metric cards; data.sections (Highlights/Risks/Asks) makes it an exec summary / 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: big section number + title; blocks = agenda progress chips (emphasis=primary = current) 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: architecture/system components: panels with internals (edges optional) or nodes wired by directed arrows takeaway_stack: a title plus a few supporting points, each with one line of detail (executive summary, key findings); 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 (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.
stylingNoTopical design on default themes (default on; the note names it): designed cover + a subject palette (from imagery_tag, or the brief). clean = neutral. Pins 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).
directionNortl typesets AND mirrors the slide right-to-left (Arabic/Hebrew). Never inferred — pass it.
highlightNoone-line emphasis callout (per-form).
image_srcNohttps URL | asset:<id> for image-bearing forms
imagery_tagNoSubject/industry: steers cover/section photos AND the topical palette. Omit = general; `education` = teaching.
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. 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_truncationNoMore items than the form holds blocks (it would drop your data); the response names the dropped count + a suggested_split. true renders the capacity subset (fidelity=verbatim_truncated). Default false.
form_descriptionNo
allow_fabricationNoBrief mode only: a bare brief on a DATA form (kpi/funnel/comparison/…) returns would_fabricate at $0 rather than INVENT numbers. Send typed fields for verbatim, or 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.

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses blocking/autofix behavior, cost thresholds ($0 invalid, $0.05 code, +$0.05 image), dry-run and polling behavior, and conditionality such as 'renders + bills only if faithful'. It goes well beyond the sparse annotations and matches them (no contradiction).

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 text is heavily front-loaded with a dense first paragraph, and the menu/escape-mode sections are clearly organized. It is long by necessity given 37 forms, but a few interstitial notes (e.g., 'the generated,always-current JSON Schema') add verbiage without much semantic weight, so it is not maximally concise.

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?

For a 42-parameter tool with no output schema, it covers the essential invocation workflow: forms, data shapes, per-form catalog lookup, modes, error recovery, costs, and image handling. Any return-value details are already captured by the detail/verify parameter descriptions in the schema, so nothing critical is missing.

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?

The description supplies the entire form menu semantics that the schema's form parameter only points to, plus the blocks-vs-data split and the meaning of mode=code/status. With 93% schema coverage the baseline is 3, but this adds genuinely necessary routing semantics well 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 first sentence states the exact operation: 'Create one PowerPoint slide (.pptx, native, editable) from a structured intent in ONE call', with explicit form/brief paths and modes. 'One ... slide' and 'inspect' via mode=status distinguish it from sibling tools like create_deck and plan_slide without ambiguity.

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?

Gives explicit routing rules: choose a form or pass a brief, consult browse_catalog for new forms and exact data shapes, use mode=code when the menu cannot express the request, and use mode=status to poll. It does not explicitly contrast sibling tools such as create_deck or plan_slide, so it misses the full cross-tool when-to-use comparison.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool maps to a distinct phase or responsibility: browse_catalog for exploration, plan_slide for pre-render planning, create_slide/create_deck for single vs multi-slide generation, upload_asset for asset intake, translate_deck for translation, and manage_account for account/job operations. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (browse_catalog, create_deck, create_slide, manage_account, plan_slide, translate_deck, upload_asset). This uniform convention makes the set predictable and easy to navigate.

Tool Count5/5

Seven tools provide a well-scoped coverage of the PowerPoint generation workflow—from browsing and planning to creating, asset management, translation, and account control—without unnecessary duplication or bloat.

Completeness5/5

The tool surface covers the full lifecycle: exploration (browse_catalog), planning (plan_slide), single/multi-slide creation (create_slide/create_deck), asset upload/generation (upload_asset), translation (translate_deck), and account/job management including deletion and webhooks (manage_account). No obvious dead ends or missing operations.