Skip to main content
Glama

SlideForge

by dev.slideforge
OverviewDiscussionsAdmin

Server Details

Deterministic, fully editable PowerPoint from typed slide intents. 200+ layouts, brand templates.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 37 days
Last Tested
Transport
Streamable HTTP · MCP 2025-03-26
URL
Repository
smartdatabrokers/slideforge-mcp
GitHub Stars
4
Server Listing
Slideforge

TDQS

A4.3/5.0

Scored across 7 tools

Disambiguation4/5

Each tool owns a distinct phase of the slide generation workflow—browse/plan/create/translate/upload/account. The only mild overlap is that create_slide can accept a brief and route it, which somewhat duplicates plan_slide's purpose.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: browse_catalog, create_deck, create_slide, manage_account, plan_slide, translate_deck, upload_asset. No mixed conventions or vague verbs.

Tool Count5/5

Seven tools is well-scoped for a PowerPoint generation server: discovery, planning, single-slide creation, deck creation, translation, asset upload, and account management each earn their place.

Completeness4/5

The surface covers the full generation lifecycle: planning, creating, deck assembly, translation, asset management, and job/account operations. Minor gaps exist such as no direct slide/deck editing or update operation, but agents can work around them.

Available Tools

7 tools
browse_catalogBrowse SlideForge's Catalog (Unified Discovery)A
Read-onlyIdempotent
Inspect

Browse the PowerPoint slide catalog progressively. No args -> form overview (when-to-use, bound fields, variant counts). family= -> variant one-liners. q= -> ranked search. variant=/prior_id= -> example payload. type=schema + family -> a compact family-level variant chooser (not a sendable contract); type=schema + family + variant -> that variant's exact payload contract (JSON Schema, capacity, field mapping, examples). Free. Code path: type=widgets = the add_widget() catalog (name= for its contract + thumbnail); type=helpers = python-pptx helper signatures. type=themes + an uploaded theme_id -> that template's branded FURNITURE layouts (its own cover/agenda/divider/closing slides + fill schemas + previews) — render via create_slide(form=template_layout, theme_id, data={layout, fills}).

ParametersJSON Schema
NameRequiredDescriptionDefault
qNoSemantic search across all variants; returns ranked form/variant matches with scores.
topNoMax results (with type=themes).
nameNoWidget name (with type=widgets): returns the full contract + worked example + a rendered thumbnail.
typeNoOmit for the form overview (or family=/q= to drill in). schema (+family, optionally +variant=) = schema-first discovery: family only returns a compact variant chooser; family+variant returns that variant's exact machine-readable payload contract (JSON Schema for data, capacity limits, intent-field mapping, examples). widgets = the add_widget() catalog for mode=code (name=<widget> for its contract). helpers = python-pptx helper signatures. themes = list themes (built-in + your saved); Default appears first and can be omitted, or use any returned id as theme_id. brands = your brand kits with versions (theme_id=<slug> renders the default version, <slug>@<n> pins n).
limitNoMax results (with q= or family=).
familyNo
offsetNoPagination offset (with q= or family=).
sourceNoTheme source filter (with type=themes). Default all (built-in + your saved).
variantNo
prior_idNo
theme_idNoWith type=themes: an uploaded theme's id -> its branded furniture layouts + fill schemas (render via create_slide(form=template_layout)).

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's added transparency about result shapes per mode, the 'Free' cost signal, capacity limits, examples, thumbnails, and the explicit 'not a sendable contract' warning is strong value beyond structured data. The description also prevents misuse by clarifying that certain outputs are for chooser/discovery and not executable contracts. No contradiction 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 dense but not wasteful — nearly every clause states a distinct mode or constraint, and the first sentence front-loads the core browsing behavior. That said, the heavy semicolon-separated run-on structure and shorthand such as 'bound fields' and 'FURNITURE' make parsing harder than necessary, so a bit more grouping or bolding would improve scannability.

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

Completeness4/5

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

For an 11-optional-parameter, multi-mode discovery tool with no output schema, the description covers most combinations, expected outputs, and even the follow-up rendering path via create_slide. Minor gaps remain, such as how q interacts with family, what type=schema alone returns, and precise return shapes for search results, but these are relatively small given the tool's complexity.

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 schema leaves several parameters like family, variant, and prior_id without property descriptions, but the description fills those gaps with concrete mode formulas: 'family=<form> -> variant one-liners', 'variant=/prior_id= -> example payload', and 'type=schema + family + variant' for the exact machine-readable contract. It also maps the ambiguous type parameter across schema, widgets, helpers, themes, and brands, adding meaning far beyond the raw 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 opens with a specific action and resource — 'Browse the PowerPoint slide catalog progressively' — and then enumerates the different browsing surfaces (form overview, variants, search, contracts, widgets, helpers, themes). This makes the tool's purpose distinct from siblings like create_slide, plan_slide, and create_deck, which actually generate presentations.

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 gives explicit mode-selection guidance: 'No args -> form overview', 'family=<form> -> variant one-liners', 'q=<text> -> ranked search', and it warns that 'type=schema + family' is 'not a sendable contract' while adding variant yields the exact payload contract. It also connects to a sibling for the next step: the theme results 'render via create_slide(form=template_layout, theme_id, data={layout, fills}).' It lacks an explicit global when-not-to-use statement versus alternatives, but the context is otherwise strong.

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

create_deckCreate Multi-Slide DeckAInspect

Create a complete PowerPoint presentation (.pptx): a whole multi-slide deck, native and editable, 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).

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.

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=).

ParametersJSON 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.
imageryNoDeck-level imagery mode, inherited by every slide (a slide-level imagery wins). See create_slide.imagery.
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.
languageNoISO 639-1 (default en) for every slide: furniture labels and authored fills follow it.
theme_idNo
directionNoDeck-level writing direction, inherited by every slide (a slide-level direction wins) — set it once for an Arabic/Hebrew deck. Covers/dividers rendered on an UPLOADED brand template keep that template's own layout direction. See create_slide.direction.
imagery_tagNoDeck-level subject declaration, inherited by every slide (a slide-level imagery_tag wins). Declare it once for a whole deck. See create_slide.imagery_tag.
force_renderNoIGNORED (deck-level). pptx_url is always returned when at least one slide rendered, so there is nothing to force. Still meaningful on create_slide.
allow_partialNoIGNORED. A deck bills per rendered slide and always returns its pptx; slides that failed or rendered badly are free and named in repair_actions.
strict_policyNoOptional CI-style gate for automated report pipelines. dry_run returns policy_result; render returns rejected/cost:0 if the policy fails.

TDQS

A5/5.0
Behavior5/5

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

Annotations are sparse, but the description discloses substantial runtime behavior: parallel filling and merging into one themed PPTX, deck-level furniture, free vs paid modes, theme_id not re-theming assembled decks, dry_run returning a validation manifest, and force_render/allow_partial being ignored. It also explains billing ('bills per rendered slide') and repair_actions for failed slides, which annotations do not convey.

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

Conciseness5/5

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

The first sentence front-loads the core action and product, and the rest is dense but purposeful. The blocked-error handling, mode explanations, and polling note are compact yet scannable, with no filler or redundant restatement of the schema.

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?

Even with no output schema, the description covers return behavior enough for invocation: pptx_url is always returned when a slide rendered, dry_run returns a per-slide manifest, policy gates return rejected/cost:0, and polling uses deck_id == job_id via manage_account. Combined with the rich schema, it gives the agent what it needs to create, validate, assemble, fork, and troubleshoot a deck.

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?

Schema coverage is already high, but the description adds meaning not present in the schema: what mode values do, why dry_run belongs at deck level, how deck_id behaves for fork/update, the ignored force_render/allow_partial behavior, and how job_ids relate to assemble. It also points to create_slide for inherited slide-level parameter semantics, reducing ambiguity.

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?

Opens with a concrete verb and resource: 'Create a complete PowerPoint presentation (.pptx): a whole multi-slide deck, native and editable, in one call.' It explicitly frames slides as create_slide intents, so an agent can distinguish deck-level creation from the single-slide sibling and from modes like assemble/fork.

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 tells when to use render vs assemble vs fork, tells the agent to see create_slide for slide-form details, routes blocked cases to browse_catalog(type=schema), and points to manage_account for job polling. It also instructs the agent to put dry_run at deck level rather than on individual slides, which is clear operational guidance.

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

create_slideCreate or Inspect a SlideAInspect

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, proven by measured results (data.results = figures) 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 (title/image-led/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 and up to 4 labelled blocks beside it, or a 1-6 picture/placeholder gallery (data.images) 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.

ParametersJSON 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
notesNoSpeaker notes for the presenter; never drawn on the slide.
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. Default `lint`: static geometry + content checks, no LLM. `lint+vlm` adds a VLM second look (~+3s); a blank render is then 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 (plain panel, no photo — only when asked). 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
languageNoISO 639-1 (default en): furniture labels and authored fills follow it.
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 library photos (covers, sections, picture slides) 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.6/5.0
Behavior5/5

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

Annotations are all false, so the description carries the full behavioral burden. It discloses cost and failure behaviors richly: BLOCKED errors with can_autofix patch merging, $0 would_fabricate/needs_confirmation outcomes, dry_run at cost:0, mode=safe billing only when faithful, wait false returning job_id for AI-image slides, force_render on completed_with_errors, and verify modes. No contradiction 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 (a ~37-item form menu) but front-loaded with the one-call create purpose. The menu is essential for form routing and each entry is a compact one-liner, so it earns its place. Some redundancy exists (mode semantics repeated in the description and in the mode parameter), but the length is justified by 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?

With 43 parameters, no required fields, rich schema descriptions, and detailed annotations, the description plus schema fully cover invocation: form selection, data shapes, escape modes, error/autofix flow, billing guardrails, and response verbosity. No output schema exists, so return-value details are not required; the tool is as complete as an agent needs.

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

Parameters4/5

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

Schema coverage is 93%, so the baseline is 3; the description adds real binding semantics: fields bind only where the form has that slot, list-shaped forms take blocks with {label, sub, detail[], emphasis}, structured forms take typed data, and browse_catalog provides the exact per-form JSON Schema and worked example. This meaningfully supplements the already-detailed property descriptions.

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 opens with 'Create one PowerPoint slide (.pptx, native, editable) from a structured intent in ONE call', which unambiguously states verb, resource, and output format. It clearly distinguishes itself from siblings like create_deck and browse_catalog by naming the slide scope and the routing mechanisms (form menu, brief, and mode). The 'Create or Inspect' title is supported via dry_run/status modes, though the emphasis remains on creation.

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 gives explicit when-to-use instructions: browse_catalog(type=schema) first for a new form, mode=code for forms the menu cannot express, mode=status to poll, and dry_run as a free pre-commit check. It does not explicitly exclude sibling tools like create_deck or plan_slide, but the single-slide scope and mode routing make the context clear and alternatives are partially addressed.

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

manage_accountAccount & HistoryA
Destructive
Inspect

SlideForge account for PowerPoint generation: balance, billing, job history, feedback, data controls. All free. Actions: status (balance+plan), usage (spend breakdown), jobs (history), job (single job detail — slide jobs include quality_warnings[]; deck jobs add slides_completed/slides_failed/failed_slides[]), feedback (submit), feedback_list (read your reports back: status + resolution), onboarding (capabilities overview), topup (Stripe checkout link; wallet credits automatically), webhooks/webhook_add/webhook_remove/webhook_test (push endpoint instead of polling to terminal), download_url (fresh short-TTL PPTX link for an owned job — when a result carries no inline URL), security_status (retention + access-model + deletion posture), delete_job (irreversible: job + versions + files) Action delete_asset irreversibly deletes a user-owned uploaded/generated image asset.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoHTTPS endpoint to receive events (for action=webhook_add). Must be public HTTPS (private/loopback rejected).
daysNoLookback period (for action=usage, default 30)
slugNoReport slug (for action=reports — returns one report's full metadata; omit to list all).
limitNoMax rows (action=jobs default 10; action=feedback_list default 50, max 100)
actionYesOperation (required). feedback → report a defect or request against a render; pass job_id so it is actionable, and ask the user before filing. feedback_list → read YOUR OWN filed reports back, with `status` and the `resolution` written when one was acted on: check it before working around a defect you reported earlier, because it may already be fixed. brand_report → the per-token fidelity report for one of your brand kits (pass theme_id). topup → mints a Stripe checkout link the user pays at directly (wallet credits automatically) — use when a render is refused for balance. reports → list report types; webhook_add registers a push endpoint instead of polling — see the url/events props. delete_job is irreversible. delete_asset is irreversible for user-owned image assets.
amountNoUSD top-up amount (for action=topup, default 10, min 10, max 1000). Volume bonus: $50→+10%, $100→+15%, $200→+20%.
detailNoFor action=status only: default false masks identity fields; true returns full email/user_id diagnostics for the authenticated user.
eventsNoEvent types to subscribe to (for action=webhook_add; default all): job.completed, job.failed, deck.completed, deck.partial, deck.failed.
job_idNoJob ID (for action=job, action=download_url and action=delete_job)
statusNoFilter — action=jobs: queued/generating/complete/failed; action=feedback_list: open/resolved
messageNoWhat went wrong or what you want, in the user's own words (for action=feedback).
asset_idNoImage asset ID (for action=delete_asset). Logos are content-addressed/shared and are not deleted by this action.
categoryNoFeedback category (action=feedback to file under it, action=feedback_list to filter by it). The first nine are slide-quality categories — pair them with job_id.
severityNoFor action=feedback: `bug` = it is broken, `quality` = it rendered but reads poorly, `suggestion` = a request. Defaults to suggestion, so file real defects explicitly or they are triaged as wishes.
webhook_idNoWebhook subscription id (for action=webhook_remove / webhook_test).
include_previewNoPreview (for action=job)
include_childrenNoFor action=jobs: include deck child slides (each carries parent_deck_id) so a deck's slides are discoverable by listing. Default false (parents only). Deck rows roll child cost up to the deck.

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing irreversibility of delete_job and delete_asset, automatic wallet credit on topup, volume bonuses, the fact that logos are content-addressed/shared and not deleted, and the severity default to 'suggestion'. These are genuinely useful behavioral details.

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 dense but front-loaded with an action inventory before detailed explanations. Given 18 actions and 17 parameters, the length is largely justified. There is some redundancy where the action parameter description repeats parts of the initial inventory, but it remains scannable.

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

Completeness3/5

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

The description covers most actions and destructive semantics thoroughly, but the missing theme_id parameter for brand_report and the conflicting reports action description are real invocation hazards. Several actions such as onboarding, webhook_test, and security_status lack expected behavior or return detail, and with no output schema the description must carry more weight than it does.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: amount volume bonuses, detail masking identity fields, include_children cost roll-up, and severity defaulting. However, it loses a point because action=brand_report tells the agent to pass theme_id, yet theme_id is not present in the schema, and reports behavior is described inconsistently between the action summary and the slug parameter.

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 opening sentence names the exact domain ('SlideForge account for PowerPoint generation: balance, billing, job history, feedback, data controls') and the action list enumerates the operations in detail. This clearly differentiates the tool from sibling tools like create_slide, create_deck, and upload_asset.

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 gives explicit selection guidance: use topup when a render is refused for balance, use webhooks instead of polling, use download_url when a result carries no inline URL, and check feedback_list before working around a previously reported defect. It also instructs the agent to ask the user before filing feedback.

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

plan_slidePlan a Slide - Form + Variant CandidatesA
Read-onlyIdempotent
Inspect

Plan a PowerPoint slide before rendering (free): send a short brief, get ranked candidates + a separated verdict — route (which slide: selected|needs_confirmation|ambiguous), input (can it render: ready|extractable_from_brief|needs_structured_data) and next_action. Free (one embedding). Then call create_slide with the chosen form(+variant). route.confidence: calibrated = measured P(route correct) with label high/medium/low cut on it; retrieval_score/retrieval_margin = the raw family-aggregated classifier values (not probabilities; margin can be negative when families contest); source = jev (calibrated router, took the route at >=0.9) | classifier | structural_router (LLM-rescued). candidate_margin on the top candidate = literal gap between the two shown scores.

ParametersJSON Schema
NameRequiredDescriptionDefault
topNo
briefYes
escalateNoDefault true: on a low-confidence route the plan runs the SAME LLM rescue create_slide would (small COGS on that tail only), so plan and create always agree. Set false for a classifier-only, fully free plan (response then flags will_escalate + create_slide_behavior).
variant_policyNoproduction_safe: if the top routed variant is draft/beta, the family's demo-safe sibling leads and route reports both best_semantic and best_production_safe.

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, and the description adds meaningful behavioral detail: it is free, uses one embedding, explains calibrated vs raw confidence semantics, and documents the source field and candidate margin. This goes well beyond what annotations provide.

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 front-loaded with the core purpose and workflow, but the second half is a dense run-on of metric definitions. Each detail is useful, but the structure could be clearer with bullets or shorter sentences.

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

Completeness4/5

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

There is no output schema, so the description rightly takes on the burden of explaining the verdict fields, confidence semantics, sources, and margins. It covers the important return values and next step, but the unexplained `top` parameter and somewhat unstructured metrics leave a small completeness gap.

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

Parameters3/5

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

The description adds useful context for brief ('send a short brief') and the schema already documents escalate and variant_policy well. However, the `top` parameter has no description in the schema or the tool description, and schema coverage is only 50%, so a meaningful parameter remains unexplained.

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 states a specific verb and resource: 'Plan a PowerPoint slide before rendering' and enumerates concrete outputs (ranked candidates, route, input, next_action). It distinguishes itself from create_slide by explicitly saying 'before rendering' and instructing the agent to call create_slide afterward.

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 gives clear usage context: use this to plan before rendering, then call create_slide with the chosen form/variant. It also clarifies cost behavior and the escalate tradeoff. It does not explicitly state when to skip planning and go straight to create_slide, so it is not a full 5.

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

translate_deckTranslate PPTXAInspect

Translate a PowerPoint (.pptx) deck preserving all formatting. $0.02/slide. Supports 35 languages (Latin, Cyrillic, Greek, Chinese, Japanese, Korean). Provide job_id (from a previous create_slide/create_deck), pptx_url, or pptx_base64.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoJob name
job_idNoSource: previous slide/deck job ID (preferred — no file transfer needed)
pptx_urlNoSource: HTTPS URL to .pptx
pptx_base64NoSource: Base64-encoded .pptx (max ~10 MB)
concise_modeNoPrefer shorter translations for tight text boxes
include_notesNoTranslate speaker notes (default false)
include_tablesNoTranslate table cells (default true)
include_previewNoWait+embed preview (default=wait)
source_languageNoSource language or 'auto' (default auto)
target_languageYesTarget language (required)

TDQS

A3.8/5.0
Behavior3/5

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

Annotations provide no hints (all false), so the description must carry behavioral disclosure. It adds value by stating formatting preservation, per-slide cost, and language support. However, it does not clarify whether the operation creates a new deck or modifies the original, nor does it mention output format or retrieval. This is a notable gap for a mutation tool.

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 compact: two sentences that lead with the core purpose, then pricing and language scope, then input methods. It avoids redundancy and is efficiently structured. The pricing detail, while not essential for invocation, is relevant context and does not bloat the text.

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

Completeness3/5

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

For a tool with 10 parameters and no output schema, the description covers the essential inputs (target language and a source) and mentions prerequisites (prior job ID). However, it does not explain what the tool returns (e.g., a new job_id or a direct download), leaving the agent without clear post-call expectations. This is a meaningful gap given the lack of output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter is already documented. The description adds minimal new meaning—it mentions job_id is preferred and summarizes the three source options, but the schema already states these. It also lists language families, but the enum in the schema is more specific. No substantial enhancement over 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 'Translate a PowerPoint (.pptx) deck preserving all formatting,' giving a specific verb and resource. It is immediately distinguishable from siblings like create_deck, create_slide, and browse_catalog, which focus on creation or browsing. The title 'Translate PPTX' reinforces the purpose.

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 specifies input sources: 'Provide job_id (from a previous create_slide/create_deck), pptx_url, or pptx_base64,' which implies usage after a deck exists. It does not explicitly compare to alternatives, but since no sibling is a translation tool, the intended context is clear. It lacks explicit 'when not to use' guidance, but the context is adequate.

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

upload_assetUpload or Generate AssetAInspect

Upload assets for PowerPoint (.pptx) generation: company template, logo, image, or document — or AI-generate an image.

Purposes: • logo — company logo for chrome (PNG/JPG/SVG, max 5MB) → logo_id • image — image for the Image component (max 10MB) → asset_id • theme — company template PPTX → theme_id; slides with it render NATIVELY on the template (masters/layouts/chrome) • generate_image — AI-generate via prompt → asset_id ($0.05) • translate — PPTX to translate → deck job_id ($0.02/slide; requires target_language) • pdf — PDF → editable slides; pass target_language to also translate • recreate — image OF a slide → editable PPTX slide ($0.10; honest annotate/preserve fallback, refusals free). Use image to just place a picture

Files >3MB (pdf/translate/theme) — and recreate on chat hosts — omit data: a drop-zone appears in the result card; bytes never pass through the agent.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataNoBase64-encoded file content. Required for logo/image/theme/translate. Optional for pdf — omit to get a drop-zone (recommended for files >3MB).
sizeNoImage dimensions for generate_image (default 1024×1024)
modelNoExplicit gateway model ID. Overrides `quality`.
job_idNoFor purpose=brand: keep the look a recreate rendered in — pass that recreate's job_id and its exact kit is saved as yours (no upload, no charge).
promptNoImage description (required when purpose=generate_image)
purposeYesAsset type (required). brand = a .pptx/.potx corporate template imported as your brand kit (theme is the same thing under its old name).
qualityNodraft = Flux Schnell. balanced (default) = Gemini Flash Image. premium = GPT Image 2. Overridden by `model`.
filenameNoOriginal filename (for type detection)
positionNoLogo position: top-left / top-right / bottom-left / bottom-right
theme_idNoFor purpose=recreate: the brand kit or built-in theme to render the recreated slide in — your kit slug, `slug@version`, or a built-in id. Omit to keep the look of the source image.
theme_nameNoName for extracted theme (purpose=theme)
target_languageNoRequired for purpose=translate. Optional for purpose=pdf — chains pdf→pptx→translate in one call.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations are all false, meaning this is a mutating operation with side effects. The description transparently discloses pricing per operation, file size limits per purpose, the behavior when data is omitted (drop-zone appears), and the fallback/refusal behavior for recreate. It also clarifies that bytes never pass through the agent when using the drop-zone, which is a useful behavioral detail.

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 organized with a bulleted purpose list and clear annotations for each purpose. It's somewhat long (8 purposes with pricing) but every sentence serves a purpose—no fluff. The key differentiators (cost, size limits, drop-zone behavior) are front-loaded in the bullets.

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

Completeness4/5

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

For a complex 12-parameter tool with 8 purposes, the description is quite complete. It explains the purpose distinctions, cost structure, and the data-omission behavior. A small gap: it doesn't explicitly state what happens on failure or how the output is returned beyond mentioning job_id and asset_id, though the schema covers most parameter semantics.

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

Parameters3/5

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

Schema coverage is 100%, so the description adds marginal value. It clarifies the practical distinctions (e.g., purpose=brand = theme under a new name, data optional for pdf but required for other purposes). The description reinforces the schema but doesn't deeply re-explain each parameter since the schema already handles that.

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 provides a detailed breakdown of each purpose with clear verbs and resource types, distinguishing between uploading and AI-generating assets. The sibling tools are completely different (browse_catalog, create_deck, create_slide), so there's no risk of confusion with this tool's core function.

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 explicitly covers when to use each purpose, which purpose is an alias for another (brand = theme), cost implications, and file-size guidance (omit data for >3MB files). It also distinguishes between recreate vs. using image to place a picture, and mentions the drop-zone fallback for chat hosts.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedupload_asset2 fields changed
      • addedInput schema / properties / job_id
        Added value: +{
+  "description": "For purpose=brand: keep the look a recreate rendered in — pass that recreate's job_id and its exact kit is saved as yours (no upload, no charge).",
+  "type": "string"
+}
      • addedInput schema / properties / theme_id
        Added value: +{
+  "description": "For purpose=recreate: the brand kit or built-in theme to render the recreated slide in — your kit slug, `slug@version`, or a built-in id. Omit to keep the look of the source image.",
+  "type": "string"
+}
  2. 2 tool updates
    • Changedcreate_deck2 fields changed
      • changedInput schema / properties / language / description
        Previous value: -"Target language"New value: +"ISO 639-1 (default en) for every slide: furniture labels and authored fills follow it."
      • changedInput schema / properties / language / enum
        Previous value: -[
-  "en",
-  "de",
-  "fr",
-  "es",
-  "it",
-  "pt",
-  "nl",
-  "pl",
-  "ru",
-  "uk"
-]New value: +[
+  "bg",
+  "ca",
+  "cs",
+  "da",
+  "de",
+  "el",
+  "en",
+  "es",
+  "et",
+  "fi",
+  "fr",
+  "gl",
+  "hr",
+  "hu",
+  "id",
+  "is",
+  "it",
+  "ja",
+  "ko",
+  "lt",
+  "lv",
+  "nl",
+  "no",
+  "pl",
+  "pt",
+  "ro",
+  "ru",
+  "sk",
+  "sl",
+  "sr",
+  "sv",
+  "tr",
+  "uk",
+  "vi",
+  "zh"
+]
    • Changedcreate_slide3 fields changed
      • changedInput schema / properties / language / description
        Previous value: -"Target language (default: en)"New value: +"ISO 639-1 (default en): furniture labels and authored fills follow it."
      • changedInput schema / properties / language / enum
        Previous value: -[
-  "en",
-  "de",
-  "fr",
-  "es",
-  "it",
-  "pt",
-  "nl",
-  "pl",
-  "ru",
-  "uk"
-]New value: +[
+  "bg",
+  "ca",
+  "cs",
+  "da",
+  "de",
+  "el",
+  "en",
+  "es",
+  "et",
+  "fi",
+  "fr",
+  "gl",
+  "hr",
+  "hu",
+  "id",
+  "is",
+  "it",
+  "ja",
+  "ko",
+  "lt",
+  "lv",
+  "nl",
+  "no",
+  "pl",
+  "pt",
+  "ro",
+  "ru",
+  "sk",
+  "sl",
+  "sr",
+  "sv",
+  "tr",
+  "uk",
+  "vi",
+  "zh"
+]
      • changedInput schema / properties / verify / description
        Previous value: -"mode=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."New value: +"mode=code. Default `lint`: static geometry + content checks, no LLM. `lint+vlm` adds a VLM second look (~+3s); a blank render is then a $0 error, not a billed warning. `off` skips checks."
  3. 1 tool update
    • Changedcreate_slide1 field changed
      • changedInput schema / properties / imagery_tag / description
        Previous value: -"Subject/industry: steers cover/section photos AND the topical palette. Omit = general; `education` = teaching."New value: +"Subject/industry: steers library photos (covers, sections, picture slides) AND the topical palette. Omit = general; `education` = teaching."
  4. 1 tool update
    • Changedcreate_slide1 field changed
      • addedInput schema / properties / notes
        Added value: +{
+  "description": "Speaker notes for the presenter; never drawn on the slide.",
+  "type": "string"
+}
  5. 2 tool updates
    • Changedtranslate_deck1 field changed
      • changedInput schema / properties / target_language / enum
        Previous value: -[
-  "en",
-  "de",
-  "fr",
-  "es",
-  "it",
-  "pt",
-  "nl",
-  "sv",
-  "da",
-  "no",
-  "fi",
-  "is",
-  "pl",
-  "cs",
-  "sk",
-  "hu",
-  "ro",
-  "hr",
-  "sl",
-  "et",
-  "lt",
-  "lv",
-  "ru",
-  "uk",
-  "bg",
-  "sr",
-  "tr",
-  "ca",
-  "gl",
-  "id",
-  "vi",
-  "el"
-]New value: +[
+  "en",
+  "de",
+  "fr",
+  "es",
+  "it",
+  "pt",
+  "nl",
+  "sv",
+  "da",
+  "no",
+  "fi",
+  "is",
+  "pl",
+  "cs",
+  "sk",
+  "hu",
+  "ro",
+  "hr",
+  "sl",
+  "et",
+  "lt",
+  "lv",
+  "ru",
+  "uk",
+  "bg",
+  "sr",
+  "tr",
+  "ca",
+  "gl",
+  "id",
+  "vi",
+  "el",
+  "zh",
+  "ja",
+  "ko"
+]
    • Changedupload_asset1 field changed
      • changedInput schema / properties / target_language / enum
        Previous value: -[
-  "en",
-  "de",
-  "fr",
-  "es",
-  "it",
-  "pt",
-  "nl",
-  "sv",
-  "da",
-  "no",
-  "fi",
-  "is",
-  "pl",
-  "cs",
-  "sk",
-  "hu",
-  "ro",
-  "hr",
-  "sl",
-  "et",
-  "lt",
-  "lv",
-  "ru",
-  "uk",
-  "bg",
-  "sr",
-  "tr",
-  "ca",
-  "gl",
-  "id",
-  "vi",
-  "el"
-]New value: +[
+  "en",
+  "de",
+  "fr",
+  "es",
+  "it",
+  "pt",
+  "nl",
+  "sv",
+  "da",
+  "no",
+  "fi",
+  "is",
+  "pl",
+  "cs",
+  "sk",
+  "hu",
+  "ro",
+  "hr",
+  "sl",
+  "et",
+  "lt",
+  "lv",
+  "ru",
+  "uk",
+  "bg",
+  "sr",
+  "tr",
+  "ca",
+  "gl",
+  "id",
+  "vi",
+  "el",
+  "zh",
+  "ja",
+  "ko"
+]
  6. 1 tool update
    • Changedupload_asset1 field changed
      • changedInput schema / properties / quality / description
        Previous value: -"draft = Flux Schnell. balanced (default) = FLUX.2 Flash. premium = GPT Image 2. Overridden by `model`."New value: +"draft = Flux Schnell. balanced (default) = Gemini Flash Image. premium = GPT Image 2. Overridden by `model`."
  7. 1 tool update
    • Changedupload_asset1 field changed
      • changedInput schema / properties / quality / description
        Previous value: -"draft = Flux Schnell. balanced (default) = Gemini Flash Image. premium = Imagen 4 Fast. Overridden by `model`."New value: +"draft = Flux Schnell. balanced (default) = FLUX.2 Flash. premium = GPT Image 2. Overridden by `model`."
  8. 1 tool update
    • Changedcreate_slide1 field changed
      • changedInput schema / properties / imagery / description
        Previous value: -"Cover/section-divider imagery: photo (default — curated stock photo, half-bleed), wash (abstract color wash), off (typographic only). Content slides are never photo-decorated."New value: +"Cover/section-divider imagery: photo (default — curated stock photo, half-bleed), wash (abstract color wash), off (plain panel, no photo — only when asked). Content slides are never photo-decorated."
  9. 3 tool updates
    • Changedbrowse_catalog1 field changed
      • changedInput schema / properties / type / description
        Previous value: -"Omit for the form overview (or family=/q= to drill in). schema (+family, optionally +variant=) = schema-first discovery: family only returns a compact variant chooser; family+variant returns that variant's exact machine-readable payload contract (JSON Schema for data, capacity limits, intent-field mapping, examples). widgets = the add_widget() catalog for mode=code (name=<widget> for its contract). helpers = python-pptx helper signatures. themes = list themes (built-in + your saved); Default appears first and can be omitted, or use any returned id as theme_id."New value: +"Omit for the form overview (or family=/q= to drill in). schema (+family, optionally +variant=) = schema-first discovery: family only returns a compact variant chooser; family+variant returns that variant's exact machine-readable payload contract (JSON Schema for data, capacity limits, intent-field mapping, examples). widgets = the add_widget() catalog for mode=code (name=<widget> for its contract). helpers = python-pptx helper signatures. themes = list themes (built-in + your saved); Default appears first and can be omitted, or use any returned id as theme_id. brands = your brand kits with versions (theme_id=<slug> renders the default version, <slug>@<n> pins n)."
    • Changedmanage_account2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Operation (required). feedback → report a defect or request against a render; pass job_id so it is actionable, and ask the user before filing. feedback_list → read YOUR OWN filed reports back, with `status` and the `resolution` written when one was acted on: check it before working around a defect you reported earlier, because it may already be fixed. topup → mints a Stripe checkout link the user pays at directly (wallet credits automatically) — use when a render is refused for balance. reports → list report types; webhook_add registers a push endpoint instead of polling — see the url/events props. delete_job is irreversible. delete_asset is irreversible for user-owned image assets."New value: +"Operation (required). feedback → report a defect or request against a render; pass job_id so it is actionable, and ask the user before filing. feedback_list → read YOUR OWN filed reports back, with `status` and the `resolution` written when one was acted on: check it before working around a defect you reported earlier, because it may already be fixed. brand_report → the per-token fidelity report for one of your brand kits (pass theme_id). topup → mints a Stripe checkout link the user pays at directly (wallet credits automatically) — use when a render is refused for balance. reports → list report types; webhook_add registers a push endpoint instead of polling — see the url/events props. delete_job is irreversible. delete_asset is irreversible for user-owned image assets."
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "status",
-  "usage",
-  "jobs",
-  "job",
-  "download_url",
-  "feedback",
-  "feedback_list",
-  "onboarding",
-  "topup",
-  "reports",
-  "webhooks",
-  "webhook_add",
-  "webhook_remove",
-  "webhook_test",
-  "security_status",
-  "delete_job",
-  "delete_asset"
-]New value: +[
+  "status",
+  "usage",
+  "jobs",
+  "job",
+  "download_url",
+  "feedback",
+  "feedback_list",
+  "onboarding",
+  "topup",
+  "brand_report",
+  "reports",
+  "webhooks",
+  "webhook_add",
+  "webhook_remove",
+  "webhook_test",
+  "security_status",
+  "delete_job",
+  "delete_asset"
+]
    • Changedupload_asset2 fields changed
      • changedInput schema / properties / purpose / description
        Previous value: -"Asset type (required)"New value: +"Asset type (required). brand = a .pptx/.potx corporate template imported as your brand kit (theme is the same thing under its old name)."
      • changedInput schema / properties / purpose / enum
        Previous value: -[
-  "logo",
-  "image",
-  "theme",
-  "generate_image",
-  "translate",
-  "pdf",
-  "recreate"
-]New value: +[
+  "logo",
+  "image",
+  "theme",
+  "brand",
+  "generate_image",
+  "translate",
+  "pdf",
+  "recreate"
+]
  10. 1 tool update
    • Changedmanage_account5 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Operation (required). feedback → report a defect or request against a render; pass job_id so it is actionable, and ask the user before filing. topup → mints a Stripe checkout link the user pays at directly (wallet credits automatically) — use when a render is refused for balance. reports → list report types; webhook_add registers a push endpoint instead of polling — see the url/events props. delete_job is irreversible. delete_asset is irreversible for user-owned image assets."New value: +"Operation (required). feedback → report a defect or request against a render; pass job_id so it is actionable, and ask the user before filing. feedback_list → read YOUR OWN filed reports back, with `status` and the `resolution` written when one was acted on: check it before working around a defect you reported earlier, because it may already be fixed. topup → mints a Stripe checkout link the user pays at directly (wallet credits automatically) — use when a render is refused for balance. reports → list report types; webhook_add registers a push endpoint instead of polling — see the url/events props. delete_job is irreversible. delete_asset is irreversible for user-owned image assets."
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "status",
-  "usage",
-  "jobs",
-  "job",
-  "download_url",
-  "feedback",
-  "onboarding",
-  "topup",
-  "reports",
-  "webhooks",
-  "webhook_add",
-  "webhook_remove",
-  "webhook_test",
-  "security_status",
-  "delete_job",
-  "delete_asset"
-]New value: +[
+  "status",
+  "usage",
+  "jobs",
+  "job",
+  "download_url",
+  "feedback",
+  "feedback_list",
+  "onboarding",
+  "topup",
+  "reports",
+  "webhooks",
+  "webhook_add",
+  "webhook_remove",
+  "webhook_test",
+  "security_status",
+  "delete_job",
+  "delete_asset"
+]
      • changedInput schema / properties / category / description
        Previous value: -"Feedback category (for action=feedback). The first nine are slide-quality categories — pair them with job_id."New value: +"Feedback category (action=feedback to file under it, action=feedback_list to filter by it). The first nine are slide-quality categories — pair them with job_id."
      • changedInput schema / properties / limit / description
        Previous value: -"Max jobs (for action=jobs, default 10)"New value: +"Max rows (action=jobs default 10; action=feedback_list default 50, max 100)"
      • changedInput schema / properties / status / description
        Previous value: -"Filter (for action=jobs): queued/generating/complete/failed"New value: +"Filter — action=jobs: queued/generating/complete/failed; action=feedback_list: open/resolved"
  11. 1 tool update
    • Changedcreate_slide1 field changed
      • changedInput schema / properties / direction / description
        Previous value: -"rtl typesets the slide right-to-left (Arabic/Hebrew). Layout is not mirrored. Never inferred — pass it."New value: +"rtl typesets AND mirrors the slide right-to-left (Arabic/Hebrew). Never inferred — pass it."

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources