Skip to main content
Glama

Create a video

create_video

Make a short video from a description, or bring a photo to life. Uses site credits with OAuth or USD with an API key; usually takes 1 to 3 minutes.

Input Schema

NameRequiredDescriptionDefault
imageNoChatGPT only: a starting photo the user attached. Use image_url everywhere else.
modelNoOptional PopNow model id (see list_models). Leave empty for the default, MiniMax H3.
promptYesWhat happens in the video, in plain words: who or what, the action, the camera and the mood.
max_usdNoAPI key only: maximum approved USD as a decimal string with up to 9 fractional digits. Set currency to USD. Only set after the user confirms the quoted cost_usd. Never convert max_credits.
currencyNoBilling unit: USD for API keys; credits for OAuth (optional for existing OAuth clients).
image_urlNoOptional starting photo (public https link or popnow:// link). With a photo, the video brings that photo to life.
max_creditsNoOAuth only: the most site credits the user agreed to spend on this. Only set it after the user confirmed a quoted price.
aspect_ratioNoShape when there is no starting photo: 16:9 (wide, default), 9:16 (phone), 1:1 (square).
duration_secondsNoLength in seconds. Default 5. Longer videos cost more.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / currency
      Added value: +{
      +  "description": "Billing unit: USD for API keys; credits for OAuth (optional for existing OAuth clients).",
      +  "type": "string"
      +}
    • changedInput schema / properties / image / type
      Previous value: -[
      -  "null",
      -  "object"
      -]New value: +"object"
    • changedInput schema / properties / max_credits / description
      Previous value: -"The most credits the user agreed to spend on this. Only set it after the user confirmed a quoted price."New value: +"OAuth only: the most site credits the user agreed to spend on this. Only set it after the user confirmed a quoted price."
    • addedInput schema / properties / max_usd
      Added value: +{
      +  "description": "API key only: maximum approved USD as a decimal string with up to 9 fractional digits. Set currency to USD. Only set after the user confirms the quoted cost_usd. Never convert max_credits.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only cover safety/idempotency; the description adds genuinely new behavior: the cost model (site credits with OAuth, USD with an API key) and expected latency of 1-3 minutes. It omits how the result comes back (async job, presumably polled via get_job), which would be the next valuable disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with zero waste; the capability statement comes first and the cost/latency facts second. Nothing redundant with annotations or schema.

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

Completeness3/5

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

For a 9-parameter, nested, non-idempotent, open-world creation tool with no output schema, the description covers cost and latency but says nothing about the asynchronous job lifecycle (submit -> poll get_job) or what identifier is returned. That is a meaningful gap for an agent to call it end-to-end correctly.

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 coverage is 100%, so the schema already documents all nine params, including the image vs image_url split and max_usd confirmation flow. The description's 'bring a photo to life' echoes image_url's own text rather than adding new meaning, so baseline 3 applies.

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?

States a specific verb and resource ('make a short video') plus the two input modes (text prompt or photo). It does not name or differentiate itself from close siblings like create_video_from_references or extend_video, which is the only thing keeping it from a 5.

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?

It gives useful context (billing by OAuth credits vs API key USD, 1-3 minute runtime) from which usage can be inferred, but never states when to pick this over create_video_from_references, compose_video, or extend_video. The agent is left to infer the routing.

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.