Ignix

Plan the edit of the user's own video

plan_video_edit

Ignix's video editor, with this brand's context: from the TRANSCRIPT of the user's own video (each word with its times) it decides the hook title, captions and emphasised words, zooms, on-screen texts and numbers, emojis, sound effects from the Ignix library, b-roll from the user's files, cuts (only if asked), the end card, and the post caption with hashtags. Returns it anchored to word indices and as a timeline in seconds. Up to 10 minutes of video. Spends 45 AI credits per started minute. OPTIONAL: by default you decide the edit yourself following get_edit_playbook (free) — call this only when the user asks for Ignix's editor. To get several short clips out of a long video use plan_clips instead. 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
`broll`	No	The user's own photos or clips that can be shown over the video: { ref: "b1".., kind: image\|video, durationSec?, description }.
`words`	Yes	Every word in order: { t: the word, s: start second, e: end second }. Up to 1800 words.
`format`	No	Aspect ratio of the result, default 9:16.
`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.
`request`	Yes	What the user asked for, in their words (e.g. "subtitles and a strong hook, remove the repeats").
`language`	No	Two-letter language of what is said (es, en…). Optional.
`platform`	No	Network it is for (instagram, tiktok…).
`cutsAllowed`	No	True only if the user asked to tighten it (cut retakes, false starts, tangents).
`durationSec`	Yes	Length of the video in seconds (max 600).
`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.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: 45 AI credits per started minute, 10-minute cap, a free dry-run mode when confirm is absent, and the requirement that a second call reuse identical arguments. It also clarifies consent scope — one yes covers the approved plan, anything new needs a new yes — which is genuine behavioral context no annotation carries.

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 purpose and content list before cost and gating rules, and every sentence carries operational weight. It is one very dense block though, and the confirm/credits rule is essentially stated twice ('SPENDS AI CREDITS ONLY WITH confirm: true' and the wait-for-yes sentence), which slightly hurts scanability.

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 11 parameters, no output schema, and an open-world mutation, the description still supplies what an agent needs: input expectation (transcript words with times), duration limits, cost model, return shape (anchored to word indices and a timeline in seconds), and the confirmation flow. Nothing essential is missing.

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 every parameter (request, words, broll, cutsAllowed, confirm, workspaceId, idempotencyKey) is already documented in the schema with equivalent phrasing. The description restates the confirm and cuts semantics rather than adding syntax or format details, so baseline 3 applies.

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 (plans the edit of the user's own video) and enumerates exactly what gets decided from the transcript: hook title, captions, zooms, on-screen texts, emojis, sound effects, b-roll, cuts, end card, post caption. It also names the two siblings it is not (get_edit_playbook as the default, plan_clips for short clips), so an agent can route without opening any schema.

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 when-not: 'by default you decide the edit yourself following get_edit_playbook (free) — call this only when the user asks for Ignix's editor', plus 'to get several short clips out of a long video use plan_clips instead'. The two-step confirmation protocol (call without confirm to get a quote, then with confirm after a clear yes) is spelled out as an operating procedure.

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?