An explainer, lesson or self-introduction spoken to camera by an AI presenter with an AI voice. Not an ad: no pitch and no call to action. Script, keyframes, scene videos and final cut, returned as an MP4. 250 credits per scene.
Scored across 3 tools
prepare_presenter_video versus generate_video are the closest pair, but the descriptions clearly separate planning (no credits, no output) from production (250 credits per scene). get_video is unambiguously read-only polling, so the only real friction is remembering the prepare-then-generate ordering.
All three follow a snake_case verb_noun pattern (prepare_presenter_video, generate_video, get_video). The noun differs slightly (presenter_video vs video), which is a minor readability wrinkle rather than an inconsistency.
Three tools map exactly onto the pipeline stages: plan, produce, poll. Nothing is redundant and nothing feels missing at the workflow level.
The core lifecycle (prepare -> generate -> poll for the MP4) is fully covered. Secondary operations an agent might expect, such as cancelling a run, listing existing videos, or regenerating a single scene, are absent but are workable gaps.
Start the AI production of a prepared video in the user's ManyMotions account: creative direction, script, keyframes, scene videos with AI voice, final cut. Call it only after the user explicitly asked to generate: it consumes credits (250 per scene). The run takes several minutes: poll with get_video. It needs the user's ManyMotions account: the client asks the user to sign in when it is missing.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| run | No | |
| state | Yes | |
| scenes | No | |
| balance | No | |
| message | Yes | |
| project | Yes | |
| dashboard_url | Yes | |
| credits_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: credit consumption per scene, multi-minute runtime with a required polling tool, and an authentication requirement (client prompts sign-in when the ManyMotions account is missing). These are exactly the traits an agent needs and none are derivable from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action, then gating/cost, then runtime and auth. Every clause carries operational information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the description covers the async pattern (poll with get_video), cost, and auth. An agent has everything needed to invoke and then track this run correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description says nothing about project_id, but the parameter is a single self-describing identifier and the operation's semantics (which project's video is rendered) are implied by context. No compensating detail is added, so this sits at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('start the AI production') plus resource ('a prepared video') with the concrete pipeline enumerated (creative direction, script, keyframes, scene videos, final cut). The word 'prepared' implicitly separates it from prepare_presenter_video, and the agent can tell it apart from get_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit gating condition ('Call it only after the user explicitly asked to generate'), an explicit cost warning (250 credits per scene), and an explicit follow-up action ('poll with get_video'). The only minor gap is that prepare_presenter_video is not named as the prerequisite, but 'prepared video' points at it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the progress of a video run in the user's ManyMotions account (which of the 7 steps are done, the script once written) and return the finished MP4 URL when the final cut is ready. Read-only: it never starts or changes a run.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| run | Yes | |
| state | Yes | |
| message | Yes | |
| video_url | No | |
| dashboard_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered; the description reinforces this ('never starts or changes a run') and adds genuinely new behavioral detail about what state is reported (which of the 7 steps are done, the script) and when the MP4 URL becomes available. It stops short of describing polling/rate behavior or how partial runs are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the core action front-loaded and the read-only caveat last, which is the right ordering. The parenthetical about the 7 steps adds precision rather than padding, though the sentence is long enough that it could be split for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description needn't enumerate return fields, yet it helpfully sketches the important ones. The only real gap is the absence of polling guidance for a progress-check tool, which is the main thing an agent needs to use it correctly over time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 0% schema description coverage, so the description carries the burden, and it only implies that project_id identifies the run within 'the user's ManyMotions account'. It adds no format, provenance, or where-to-obtain guidance for project_id. Adequate but thin for the sole input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check the progress of a video run'), names the concrete return ('the finished MP4 URL when the final cut is ready'), and the read-only clause implicitly separates it from generate_video, which starts a run. An agent can route between this and its siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for use: polling progress of an existing run and retrieving the output URL. The line 'it never starts or changes a run' implies generate_video is the tool for starting one, but no alternative is named explicitly and no precondition (e.g. an existing project_id from a prior run) is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a talking AI avatar presenter video with ManyMotions: an explainer or lesson that teaches one concept, or a self-introduction for a person, a business or a channel, spoken to camera by an AI presenter with an AI voice. Not an advertisement: no product pitch and no call to action. ManyMotions writes the script scene by scene, generates the keyframes and the scene videos with AI voice, and edits the final cut. Returns the plan: scene count and credits required. Nothing is generated and no credits are spent. No sign-in is needed to prepare. New videos from text only: do not use it for uploaded or existing footage, photos of real people, editing, captions or dubbing; for those, point the user to ManyMotions.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | What the video explains, or who or what it introduces. | |
| format | No | Aspect ratio: 9:16 (default, TikTok, Reels, Shorts), 1:1, 4:5 or 16:9 (YouTube). | |
| audience | No | Who it is for and their level, e.g. high-school students, new employees, beginners. | |
| duration | No | Target length: 8s = 2 scenes, 15s = 3 (default), 30s = 5, 45s = 7, 60s = 8. 250 credits per scene. | |
| language | No | Spoken language. Default English. | |
| presenter | No | How the AI presenter looks and sounds, e.g. a friendly teacher in her 40s in a bright classroom. | |
| key_points | No | Points, facts or steps that must be covered. | |
| video_type | No | explainer (default): teaches one concept, lesson or how-to; introduction: introduces a person, a business or a channel. | |
| speech_speed | No | Default medium. |
| Name | Required | Description |
|---|---|---|
| run | No | |
| state | Yes | |
| scenes | No | |
| balance | No | |
| message | Yes | |
| project | Yes | |
| dashboard_url | Yes | |
| credits_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavior beyond the annotations: it returns a plan (scene count and credits required), spends no credits, and requires no sign-in. With readOnlyHint=false the annotation alone would not tell an agent that nothing is generated, so this is valuable disclosure. It stops short of describing plan validity or what happens on repeat calls (idempotentHint=false), leaving a small gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then scope exclusions, then the return/cost contract. Dense but each sentence carries information; the long semicolon-chained exclusion sentence is slightly harder to parse than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be detailed, yet the description still surfaces the key contract (plan returned, no credits spent, no sign-in). For a 9-parameter tool with 100% schema coverage, nothing an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the duration-to-scene mapping and the 250-credits-per-scene cost, so the description adds little parameter meaning beyond restating credit/scene output. Baseline 3 is appropriate when the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Prepare a talking AI avatar presenter video with ManyMotions') and immediately names the two supported genres, explainer/lesson vs self-introduction. It also draws an explicit boundary ('Not an advertisement') that separates it from the sibling generate_video, so an agent can disambiguate without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not conditions: not for uploaded or existing footage, photos of real people, editing, captions or dubbing, and routes those cases to ManyMotions. It also clarifies this is text-only and preparation-only, which prevents the most likely misinvocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_videoget_videoprepare_presenter_video
Add one secure layer between your agents and this server.