A travel guide, journey diary or short documentary about a destination, narrated over generated scenes of the place, returned as an MP4. 250 credits per scene.
Scored across 3 tools
Each tool fills a distinct stage of one pipeline: prepare_travel_video plans without spending credits, generate_video runs the paid production, and get_video only polls progress read-only. The descriptions explicitly bound each tool (e.g. 'call it only after', 'nothing is generated'), leaving no realistic misselection.
All three follow a verb_noun snake_case pattern (prepare_travel_video, generate_video, get_video), which is readable and predictable. The only deviation is that the prepare tool embeds a domain qualifier ('travel') while the other two use the generic 'video' object, a minor inconsistency.
Three tools map cleanly onto the narrow purpose of producing a travel/documentary video: plan, generate, poll. It is slightly thin since there is no way to list, cancel, or delete runs, but nothing is redundant and each tool earns its place.
The core lifecycle (plan → generate → retrieve finished MP4) is fully covered with no dead ends for the primary workflow. Gaps are secondary: no listing of past videos, no cancellation of an in-flight run, and no way to revise a prepared plan before generating.
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 travel or documentary video with ManyMotions about a destination, a journey or a place: a travel guide, a first-person journey diary or a short documentary, with narration over generated scenes of the place. 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. Original characters only: do not use it for copyrighted characters, existing franchises or real celebrities; offer the user an original alternative instead.
| Name | Required | Description | Default |
|---|---|---|---|
| angle | No | travel-guide (default), journey-diary or documentary. | |
| format | No | Aspect ratio: 9:16 (default, TikTok, Reels, Shorts), 1:1, 4:5 or 16:9 (YouTube). | |
| audience | No | Who it is for, e.g. budget backpackers, families, history lovers. | |
| 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. | |
| highlights | No | Places, moments, facts or tips to include. | |
| destination | Yes | The place or journey, e.g. Kyoto in autumn, a road trip through Patagonia. |
| 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?
Annotations only declare readOnlyHint=false, idempotentHint=false and destructiveHint=false; the description goes well beyond them by stating that nothing is generated, no credits are spent, no sign-in is required, and what the response contains (scene count and credits required). It also discloses the content-safety constraint (original characters only), which no annotation conveys.
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?
Purpose is front-loaded in the first sentence, followed by the pipeline, the return value, the no-side-effects guarantee, and finally the two exclusion blocks. Each sentence carries distinct information (what it does, what it returns, what it does not do, what to use instead) with no repetition.
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?
Despite seven parameters and an output schema, the description covers everything an agent needs to decide and route: scope, side-effect profile, auth requirement, return summary and two explicit out-of-scope categories with alternatives. Nothing material is missing for a tool of this complexity.
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%, including enum labels, defaults, max lengths and the credits-per-scene cost, so the schema already carries parameter meaning. The description reinforces the credits/scene relationship at a high level but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.
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 (prepare) and resource (travel/documentary video) and enumerates the three supported sub-genres (travel guide, journey diary, documentary). It also distinguishes itself from the siblings generate_video and get_video by clarifying that nothing is actually generated here — only a plan is returned.
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 when-to-use ('New videos from text only') and multiple when-not clauses: uploaded/existing footage, photos of real people, editing, captions, dubbing, copyrighted characters, franchises and real celebrities. It also names the routing destination for those cases ('point the user to ManyMotions') and states the no-sign-in prerequisite.
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_travel_video
Add one secure layer between your agents and this server.