Skip to main content
Glama
runapi-ai

RunAPI Vidu MCP Server

by runapi-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

image_to_video

Generate a Vidu video from a first-frame image URL by creating an asynchronous RunAPI task with optional prompt and audio. Returns a task ID, status, and output URLs.

Instructions

Create a Vidu task on RunAPI (image to video). Returns a task id, status, and output URLs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoPoll until the task reaches a terminal status.
audioNoGenerate synchronized audio. False produces a silent video. Declared type: boolean.
modelNoRunAPI model slug for this model line.
promptNoOptional video description, up to 20,000 characters. Declared type: string.
timeout_msNo
callback_urlNoRunAPI customer callback URL for the terminal task result. Declared type: string.
duration_secondsNoVideo duration in seconds. Declared type: integer.
poll_interval_msNo
output_resolutionNoOutput video resolution. Declared type: string. Known values: "540p", "720p", "1080p", "2k", "4k".
first_frame_image_urlYesHTTP(S) URL of a JPG, JPEG, PNG or WEBP first frame, up to 50 MB. The provider validates the remote file. Declared type: string.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the asynchronous submit-task pattern and the shape of the return (task id, status, output URLs), which is real value. However, it says nothing about auth requirements, cost implications (a check_pricing sibling exists), or how wait/poll_interval_ms change behavior.

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 short sentences with zero filler; the action is front-loaded and the return contract follows immediately.

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 10-parameter tool with no annotations and no output schema, the description does cover the return values (compensating for the missing output schema) but leaves the async/polling workflow, auth, and cost context unexplained. Adequate but with clear gaps.

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 80%, so the schema already documents most parameters including the image URL constraints and resolution values. The description adds no parameter-level detail beyond the schema, so the 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 ('Create a Vidu task ... image to video') and the parenthetical disambiguates it from the sibling reference_to_video. It stops short of explicitly routing the agent between the two video-generation siblings, but the purpose is unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to pick this over reference_to_video, no mention that get_task exists for retrieving results of a submitted task, and no prerequisites (e.g. login) are stated. The agent is left to infer usage entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools