Skip to main content
Glama

Render Deck to Video

antix_render_deck_video

Turn a finished carousel deck into an MP4 that is SAVED IN THE USER'S AIGE ACCOUNT (it appears in their AIGE history and in antix_get_history). FREE — it spends no credits. Each slide is rendered server-side at full resolution and held for secondsPerSlide (1-10s, default 3), joined either with a short crossfade (transition = fade, the default) or with hard cuts (transition = none). 2-10 slides, 60 seconds maximum, 1080p at the deck's own carousel aspect (1:1, 4:5 or 9:16) — a deck of any other shape is refused as DECK_ASPECT_UNSUPPORTED rather than silently letterboxed. Optional audioUrl must be a plain https URL on an AIGE media host, and is trimmed to the video length.

This is ASYNCHRONOUS: it returns a taskId plus the exact durationSeconds the file will run — then poll antix_check_task, which returns the poster, the play link and the direct .mp4 URL. Renders are limited to 6 per 5 minutes per account, and a replay (reusing the same idempotencyKey) counts against that too. If that task comes back failed with DECK_VIDEO_BUSY, the render queue was full and NOTHING was retried for you: wait a few minutes, then call antix_render_deck_video again, omitting idempotencyKey or passing a new one (reusing the old key just hands back the same failed task). Server-rendered slides are faithful layout approximations, not the browser's pixel-exact export; say so if the user asks about fidelity.

Instagram autopublish is NOT available — this renders a file and saves it to the account; hand it to the user or to their own scheduler. To post to a connected Instagram/Threads channel instead, use antix_compose_social_post.

Input Schema

NameRequiredDescriptionDefault
deckIdYesThe deck to render. Get ids from antix_get_deck.
audioUrlNoOptional soundtrack. Must be a plain https URL on an AIGE media host (no custom port, no embedded credentials); it is trimmed to the video length.
projectIdNoAIGE work project the finished video is filed under. Get ids from antix_list_projects.
transitionNoSlide-to-slide transition. Default fade (a short crossfade); none gives hard cuts.
idempotencyKeyNoReusing a key returns the SAME task instead of starting a second render. Omit it (or use a new one) when you deliberately want another render.
secondsPerSlideNoHow long each slide is held, in seconds (1-10). Default 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The annotations only cover destructiveHint/idempotentHint. The description adds the async taskId contract, the account-global rate limit of 6 renders per 5 minutes, the fact that a key-replay counts against it, the cost (free, no credits), the input validation of deck aspect (DECK_ASPECT_UNSUPPORTED rather than letterboxing), the queue-full failure mode, and the fidelity caveat. That is exactly the kind of context annotations cannot 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?

Front-loaded with the outcome (MP4 saved to the account) and the cost (free), then the async contract. It is dense but every sentence earns its place; the uppercase emphasis and parenthetical asides make it slightly heavier than necessary.

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?

No output schema exists, but the description fully covers what comes back: a taskId plus durationSeconds, then polling that yields poster, play link and direct .mp4 URL. It also covers the failure path and the fidelity caveat, so an agent can call and follow up correctly without other sources.

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 description coverage is already 100%, so the baseline is 3. The description adds real meaning beyond the schema: how secondsPerSlide affects the held duration, what transition=fade actually does, that audioUrl is trimmed to the video length, and that reusing idempotencyKey after a failure hands back the same failed task instead of retrying.

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?

States a specific verb and resource: turns a finished carousel deck into an MP4 saved in the user's AIGE account. It also distinguishes itself from the nearest siblings by name: antix_compose_social_post for actually posting, and antix_check_task for polling the result.

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?

Explicitly scopes when to use it (render a file and hand it off) and when not to (Instagram/Threads autopublish is NOT available — use antix_compose_social_post). It also names the follow-up step (poll antix_check_task) and the retry procedure after DECK_VIDEO_BUSY.

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.

Resources