Ignix

Generate a video with AI

generate_video

Start an AI video generation job (text-to-video, image-to-video, or an avatar reading a script). ASYNCHRONOUS: it returns a jobId; poll get_media_job until status is "done" to obtain the URL. Generation usually takes 1-5 minutes. Requires a provider configured by the organization (see list_media_providers). For a reel or Short, start with get_reel_playbook (the reel is built there); a clip from here can be one of its beats. This is one of the two ways; the other is Ignix Creator (get_creator_setup), with Ignix AI credits and no key. Ask which one only when both are available; otherwise use the one there is (no provider → Creator). Write a scene prompt following get_shot_guide("h3_clip"); with shot the server composes it and checks the minimum fields. SPENDS AI CREDITS ONLY WITH confirm: true. Call it first without confirm: nothing runs and nothing is charged, you get the quote (what it will do and the credits). Tell the user, in your own words, exactly that — including the options you chose, so they can change them — and wait for a clear yes before calling again with the same arguments and confirm: true. One yes covers the plan they approved (e.g. every line of an approved voice-over with the chosen voice); anything new or different needs a new yes.

Input Schema

Name	Required	Description
`shot`	No	Optional structured shot: the server composes the prompt from it (after `prompt`, if any) and checks the minimum fields of its type (get_shot_guide).
`aspect`	No	Aspect ratio. Use 9:16 for reels, shorts and TikTok.
`prompt`	No	For video providers: the scene to generate (optional with `shot`). For avatar providers: the exact SCRIPT the avatar will say.
`confirm`	No	true ONLY after the user said yes to the quote (what it does and the credits). Without it nothing runs and nothing is charged.
`quality`	No	Quality/cost trade-off, on the client's own key: 'high' = Kling pro mode / Veo 1080p (16:9 only, forces 8s); 'eco' = Veo fast model (fewer credits). Other providers ignore it.
`voiceId`	No	Voice for avatar providers.
`avatarId`	No	Avatar to use. Required for avatar providers (see list_avatar_options).
`imageUrl`	No	Starting image for image-to-video (only providers with supportsImage).
`provider`	Yes	Provider id from list_media_providers.
`background`	No	Solid background colour as #rrggbb hex (HeyGen avatar videos only).
`workspaceId`	No	Workspace to work on (an id from list_workspaces). Not needed when this connection is tied to one workspace, or when you pass an account: the account's workspace is used.
`attachToPostId`	No	Optional: attach the finished video to this post automatically when the job ends.
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.
`negativePrompt`	No	What to AVOID in the video (Kling only; e.g. "on-screen text, crowds").
`durationSeconds`	No	Length in seconds where the provider allows choosing: 5 or 10 (Runway, Kling); 4, 6 or 8 (Veo).

Output Schema

Name	Required	Description
`jobId`	No
`status`	No
`promptTip`	No
`confirmToken`	No
`promptWarnings`	No	What the server checked and found missing (warnings: it still generated). needs_customer_fact = ask the person before the next one.
`estimatedCredits`	No
`needsConfirmation`	No	true = this is only the quote: nothing was done or charged.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 1, 2026

changedInput schema / properties / prompt / description

Previous value: -"For video providers: the scene to generate. For avatar providers: the exact SCRIPT the avatar will say."New value: +"For video providers: the scene to generate (optional with `shot`). For avatar providers: the exact SCRIPT the avatar will say."

addedInput schema / properties / shot

Added value: +{
+  "description": "Optional structured shot: the server composes the prompt from it (after `prompt`, if any) and checks the minimum fields of its type (get_shot_guide).",
+  "properties": {
+    "action": {
+      "description": "Beats with seconds: [\"0-2 s: …\", \"2-5 s: …\"].",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "avoid": {
+      "description": "What must not appear.",
+      "type": "string"
+    },
+    "camera": {
+      "description": "Shot type + movement + speed.",
+      "type": "string"
+    },
+    "keep": {
+      "description": "What must not change.",
+      "type": "string"
+    },
+    "lens": {
+      "description": "Images: lens and depth of field.",
+      "type": "string"
+    },
+    "light": {
+      "description": "Direction, hard/soft, colour temperature.",
+      "type": "string"
+    },
+    "look": {
+      "description": "Photo or illustration, colour treatment.",
+      "type": "string"
+    },
+    "physics": {
+      "description": "What moves on its own: hair, fabric, water, smoke.",
+      "type": "string"
+    },
+    "sound": {
+      "description": "Dialogue, music, ambience.",
+      "type": "string"
+    },
+    "subjects": {
+      "description": "Who or what appears; real = it exists (the customer, their product, their place).",
+      "items": {
+        "properties": {
+          "kind": {
+            "enum": [
+              "person",
+              "product",
+              "place"
+            ],
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "real": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "kind",
+          "name",
+          "real"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "where": {
+      "description": "Place, time of day, weather.",
+      "type": "string"
+    },
+    "who": {
+      "description": "Age, looks, clothing, hair; people: real skin, natural hands.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

changedInput schema / required

Previous value: -[
-  "provider",
-  "prompt"
-]New value: +[
+  "provider"
+]

addedOutput schema / properties / promptTip
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / promptWarnings

Added value: +{
+  "description": "What the server checked and found missing (warnings: it still generated). needs_customer_fact = ask the person before the next one.",
+  "items": {
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "code",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed4 schema fields changedOct 22, 2026

addedOutput schema / properties / confirmToken
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / estimatedCredits
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / needsConfirmation

Added value: +{
+  "description": "true = this is only the quote: nothing was done or charged.",
+  "type": "boolean"
+}

removedOutput schema / required
```
Removed value: -[
-  "jobId"
-]
```

First observedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnly=false and openWorld=true; the description adds the genuinely non-obvious behavior: the job is asynchronous, takes 1-5 minutes, spends AI credits, and — critically — nothing runs or is charged without confirm: true, with a quote-first protocol. It also scopes a single 'yes' to the approved plan and requires a new yes for changes, which no annotation could convey.

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 purpose and async contract are front-loaded, and the confirm/credits warning is capitalized so it is hard to miss. The middle section is one dense run-on covering reel routing, provider choice, shot guide and credits, which could be split into shorter sentences without losing content.

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 15-parameter, nested-schema, mutating, open-world tool this leaves nothing an agent needs missing: prerequisites, async polling, credit/confirmation flow, alternative tooling and cross-references to list_media_providers, get_shot_guide and get_reel_playbook are all present, and an output schema exists so return values need not be explained.

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 baseline is 3, but the description adds real semantics the schema lacks: confirm is framed as a quote/approval protocol rather than a flag, shot vs prompt ordering is explained (server composes after `prompt`), and provider-dependent parameters are tied to the provider-selection step. It stops short of explaining every provider-specific parameter, keeping it at 4.

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 specific verb and resource plus the three supported modes (text-to-video, image-to-video, avatar script), which distinguishes it from generate_image, generate_voiceover and generate_sound_effect. The async contract (jobId + poll get_media_job) is stated in the first two sentences, so an agent knows exactly what it gets back.

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?

Explicit routing: for reels/Shorts start with get_reel_playbook; the alternative path is Ignix Creator via get_creator_setup; 'ask which one only when both are available; otherwise use the one there is (no provider → Creator)'. Prerequisites (provider from list_media_providers, shot guide from get_shot_guide) are named, and exclusions are stated rather than implied.

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

All Ignix tools Inspect

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

Need Help?