Skip to main content
Glama

Animation

animation_create_video

MCP guidance:

  • Starts an async video job; returns id and credits_charged. For finished results, call wait_for_video_project with that id or poll GET /v1/video-projects/{id} until complete, error, or canceled. Results include downloads; wait helpers add exact_download_urls. Preserve signed URLs and query parameters; never append expiration metadata.

  • For *_file_path, use an existing Magic Hour path or the upload-URL endpoint's file_path after uploading raw bytes to its presigned URL. Direct public media URLs may work if stable and fetchable as raw bytes; hotlinked URLs can fail. Prefer the upload-URL endpoint when unsure.

Create a Animation video. The estimated frame cost is calculated based on the fps and end_seconds input.

Input Schema

NameRequiredDescriptionDefault
fpsYesThe desire output video frame rate
nameNoGive your video a custom name for easy identification.Animation - dateTime
styleYesDefines the style of the output video
widthYesThe width of the final output video. The maximum width depends on your subscription. Please refer to our [pricing page](https://magichour.ai/pricing) for more details
assetsYesProvide the assets for animation.
heightYesThe height of the final output video. The maximum height depends on your subscription. Please refer to our [pricing page](https://magichour.ai/pricing) for more details
end_secondsYesThis value determines the duration of the output video.

Output Schema

NameRequiredDescriptionDefault
idYesUnique ID of the video. Use it with the [Get video Project API](https://docs.magichour.ai/api-reference/video-projects/get-video-details) to fetch status and downloads.
credits_chargedYesThe amount of credits deducted from your account to generate the video. If the status is not 'complete', this value is an estimate and may be adjusted upon completion based on the actual FPS of the output video. If video generation fails, credits will be refunded, and this field will be updated to include the refund.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / assets / example
      Added value: +{
      +  "audio_file_path": "api-assets/id/1234.mp3",
      +  "audio_source": "file",
      +  "image_file_path": "api-assets/id/1234.png"
      +}
    • changedInput schema / properties / end_seconds / example
      Previous value: -15New value: +5
    • changedInput schema / properties / height / example
      Previous value: -960New value: +512
    • addedInput schema / properties / style / properties / art_style_custom / example
      Added value: +"Watercolor painting with soft pastel colors"
  2. Changed1 schema field changed
    • removedInput schema / properties / context
      Removed value: -{
      -  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
      -  "type": "string"
      -}
  3. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare readOnly=false, destructive=false and openWorld=true; the description goes much further by disclosing that the job is asynchronous, what is returned (`id`, `credits_charged`, `downloads`, `exact_download_urls` from wait helpers), terminal states, that signed URLs and query params must be preserved, and that hotlinked media URLs can fail while direct fetchable URLs may work.

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?

Behavioral guidance is front-loaded in bullets and every bullet carries actionable content. There is mild redundancy — the file-upload guidance largely restates the `audio_file_path`/`image_file_path` schema descriptions — and the closing "Create a Animation video" line is awkward and adds little beyond the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists and annotations cover the safety profile, the description still supplies the async workflow, asset-resolution rules and a cost note, so it is nearly complete. The one material omission is sibling differentiation — nothing here tells an agent why to choose Animation over the other create_video tools.

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 the baseline is 3, but the description adds meaning beyond the schema: it ties cost to `fps` and `end_seconds`, and adds the practical caveat that hotlinked URLs can fail and upload-URL endpoints should be preferred. It does not explain the nested `style`/`assets` conditionals further than the schema already does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ("Create a Animation video") and frames it as an async job that returns an id. However, it never distinguishes this tool from the many sibling video creators (text_to_video_create_video, image_to_video_create_video, ai_video_editor_create_video), so an agent must infer the choice from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is real conditional guidance for `*_file_path` (use an existing Magic Hour path or the upload-URL endpoint; prefer the upload-URL endpoint when unsure) and lifecycle guidance (call wait_for_video_project or poll until complete/error/canceled). But it never says when to pick this Animation tool over the sibling video-creation tools, which is the primary selection decision for an agent.

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