Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Movoa MCP server make a 5-second video of a cat surfing at sunset with sound"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Unlimited AI video generator with sound: on paid plans the tenth take of a shot costs what the first did, and your first clip is free to make right now. This is the official MCP server for Movoa: it lets Claude, Cursor, Cline, Gemini CLI or any MCP client make video clips with sound on your own Movoa account. Ask for a clip in chat, get the file URL back.
Text to video: describe the shot, and the sound comes back in the same file.
Photo to video: pass a photo as image_url and it becomes the first frame.
MiniMax H3 is the default model; Seedance 2.5, Seedance 2.0 (Fast, Mini) and Veo 3 Fast are there too. Every one of them returns AI video with audio.
Tool | What it does |
| Text to video, or photo to video with |
| Status of a run, and the video URL when it is ready |
| Credits left on your account (free to call) |
Related MCP server: @vidofy/mcp
Create one at movoa.ai/settings/apikeys and set it as MOVOA_API_KEY. Runs cost credits on your Movoa account, at the prices on movoa.ai/pricing.
npx -y movoa-mcp{
"mcpServers": {
"movoa": {
"command": "npx",
"args": ["-y", "movoa-mcp"],
"env": { "MOVOA_API_KEY": "sk-..." }
}
}
}Claude Code in one line: claude mcp add movoa -e MOVOA_API_KEY=sk-... -- npx -y movoa-mcp
https://movoa.ai/api/mcpSend your key with each request as Authorization: Bearer sk-.... Listing the tools needs no key; running one does. Claude Code: claude mcp add --transport http movoa https://movoa.ai/api/mcp --header "Authorization: Bearer sk-..."
gemini extensions install https://github.com/hanshs474/movoa-mcpclaude plugin marketplace add hanshs474/movoa-mcp
claude plugin install movoa@movoaThe plugin also ships the movoa-video skill, which works without MCP (plain curl).
| Length ( |
|
|
| 4, 5, 6, 8, 10, 15 s | 480p, 768p | 16:9, 9:16, 1:1 |
| 5–30 s, steps of 5 | 480p, 720p | 16:9, 9:16, 1:1 |
| 8 s | 720p | 16:9, 9:16 |
| 4, 6, 8, 10 s | 480p, 720p | 16:9, 9:16, 1:1 |
Video takes minutes. generate_video returns a run id by default; poll it with check_status, or pass wait: true to block (up to 30 minutes).
Your plan's concurrency limit applies; a submit past it is refused until a run finishes.
MOVOA_BASE_URL overrides the endpoint; only useful against a local build of the site.
MIT
Read the status of a run started with generate_video, and the video URL when it is ready.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Keep polling every 10 seconds until it finishes. Default false. | |
| run_id | Yes | The run id returned by generate_video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that this is a read operation and that the video URL is returned only when ready, but it omits polling behavior, failure states, and what the response looks like beyond the URL, leaving meaningful gaps.
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?
The description is a single efficient sentence with no wasted wording. The core action and the return condition are front-loaded.
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?
For a simple two-parameter tool with full schema descriptions, the definition covers the essential purpose and return condition. It is slightly incomplete because it does not mention status values or failure cases, but the schema handles the wait parameter and the tool's scope is narrow.
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 100%, so both parameters are already documented in the schema, including the run_id provenance and the wait polling behavior. The description does not add parameter-level detail beyond what the structured schema provides, so the baseline score of 3 applies.
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?
The description states a specific verb (read), resource (status of a run), and result (video URL when ready). It explicitly ties the tool to runs started with generate_video, distinguishing it from that sibling and from credits.
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?
Usage is implied by 'started with generate_video,' which tells the agent this is a follow-up tool. However, it does not explicitly state when not to use it, how often to call it, or what to do if the run has not started.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The credits left on the Movoa account behind MOVOA_API_KEY. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the burden, and it does disclose two useful traits beyond the name: the result is scoped to the account behind the current API key, and the call consumes no credits. It does not state read-only nature explicitly, return shape, or whether the balance is live versus cached.
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?
Two short sentences, front-loaded with the resource and followed by the cost hint; nothing is padded. The phrasing 'the Movoa account behind MOVOA_API_KEY' is slightly tangled but still parsed in one pass.
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?
For a zero-param read with no output schema, the agent still doesn't know the return shape (integer credits, currency, structured object) or whether the value is account-level or per-key. Adequate for calling it, thin for interpreting the result.
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?
Zero parameters, so there is nothing to disambiguate — baseline 4 applies. The description correctly signals the implicit input is the API key context rather than any argument.
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 the specific resource returned — the credit balance remaining on the account tied to MOVOA_API_KEY — which is clearly distinct from generate_video (a mutation) and distinguishable in spirit from check_status. It lacks an explicit verb ('retrieve'/'get'), which keeps it just shy of a 5.
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?
No guidance on when to call this versus check_status, which plausibly reports overlapping account state. 'Free to call' hints at cost, not at selection criteria, and no preconditions (e.g., whether an exhausted balance blocks generate_video) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a video clip with sound from a text prompt on movoa.ai, or animate a photo by passing image_url (photo to video). Defaults to MiniMax H3 at 480p. Runs cost credits on your Movoa account, at the prices on https://movoa.ai/pricing. Video takes minutes: by default this returns a run id to poll with check_status.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Block until the clip is ready (up to 30 minutes). Default false. | |
| model | No | Default minimax-h3, the lowest-cost model. | |
| prompt | Yes | The shot: what happens, where, how the camera moves, and what it sounds like. | |
| duration | No | Seconds. minimax-h3: 4/5/6/8/10/15; seedance-2-5: 5–30 in steps of 5; seedance-2 family: 4/6/8/10; veo-3-1-fast: 8. | |
| image_url | No | Optional photo (public https URL) used as the first frame — makes this photo to video. | |
| resolution | No | minimax-h3: '480p' or '768p'; Seedance: '480p' or '720p'; Veo: '720p'. | |
| aspect_ratio | No | '16:9' (default), '9:16' or '1:1' (Veo: 16:9 or 9:16). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that runs cost credits (with a pricing URL), that generation takes minutes, and the exact async contract (returns a run id by default vs. blocking with wait up to 30 minutes). It omits failure/refund behavior and rate limits, which would be needed for a 5.
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?
Dense but tight: mode selection, defaults, cost, latency, and the polling contract are all front-loaded in roughly four sentences 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?
There is no output schema, but the description explains exactly what comes back (a run id) and how to follow up (check_status, or 'wait'), plus cost and latency expectations. Combined with 100% schema coverage on all 7 params, an agent has everything needed to call it 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 description coverage is 100%, so parameters such as duration/model enums and aspect_ratio constraints are already fully documented. The description only restates the minimax-h3/480p default and the image_url photo-to-video switch, which the schema already conveys — baseline 3 applies.
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+resource ('generate a video clip with sound') and explicitly covers both modes — text-to-video and photo-to-video via image_url. It also names the default model/resolution and routes to the sibling 'check_status', so an agent can distinguish it from 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?
Gives clear selection conditions: pass image_url to animate a photo, otherwise generate from prompt; default is async with a run id to poll via check_status, with 'wait' to block. It lacks explicit 'when not to use this' or guidance on model selection tradeoffs beyond that minimax-h3 is lowest cost.
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.
v0.1.0check_statuscreditsgenerate_videoScored across 3 tools
Each tool targets a clearly different concern: starting a generation, polling a run, and checking account credits. There is no plausible way to confuse them, and the async generate/check pair is explicitly linked in the descriptions.
check_status and generate_video follow a consistent verb_noun snake_case pattern, while credits is a bare noun. The deviation is readable and arguably natural for an account-balance query, but it does break the pattern.
Three tools is lean but well-matched to a focused async video-generation API: submit, poll, and check balance. Nothing feels redundant, though the surface is minimal enough that a couple more lifecycle tools would not feel heavy.
The core lifecycle is covered: generate_video returns a run id, check_status polls and surfaces the resulting URL, and credits covers billing concerns. Gaps are minor — no way to list past runs, cancel an in-flight run, or retrieve failure details beyond status.
Generate AI video from any MCP client. Pick the model, see the per-second price before you spend.
Direct AI video, image, music and storyboard production from any MCP client.
Plan, compare, price, generate, and recover AI video from compatible MCP clients.
Build, run, schedule, and publish AI video pipelines to YouTube and TikTok from any MCP client.
