Enables text-to-video generation via the Replicate API, including starting a video generation from a prompt (optionally with a first-frame image), checking generation status by ID, and downloading finished videos to disk. Supports the minimax/video-01 model by default and any Replicate video model that accepts a prompt input.
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., "@video-mcp Make a 6-second video of a red fox running through a snowy forest"
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.
An MCP server that gives Claude the ability to generate videos from text using the Replicate API.
Just ask Claude: "Make a 6-second video of a red fox running through a snowy forest" — and get a video link (or a file on your disk) a couple of minutes later.
You ──► Claude Desktop ──► video-mcp (this server) ──► Replicate API ──► video model
◄──────────── video URL / .mp4 file ◄──────────────Claude decides when to call the tools, writes a good prompt for the video model, waits for the result and shows you the link.
Related MCP server: Sora MCP Server
Tool | What it does |
| Starts video generation from a text prompt (optionally with a first-frame image). Waits up to ~50 s, then returns either the video URL or a generation ID. |
| Checks the status of a generation by ID and returns the URL when it's ready. |
| Downloads a finished video to |
Default model: minimax/video-01 (6 s, 720p). Any Replicate video model that accepts a prompt input can be used via the model argument or the VIDEO_MODEL env variable.
uv (Python package manager — it installs Python and dependencies automatically)
A Replicate API token: https://replicate.com/account/api-tokens (paid, billed per generation)
git clone https://github.com/kuuuuorti/video-mcp.gitOpen Claude Desktop → Settings → Developer → Edit Config and add:
{
"mcpServers": {
"video": {
"command": "uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/video-mcp", "run", "server.py"],
"env": {
"REPLICATE_API_TOKEN": "r8_your_token_here"
}
}
}
}Windows path example: "C:\\Users\\you\\video-mcp".
Restart Claude Desktop completely. The video server should appear in the tools menu.
Variable | Default | Description |
|
| Replicate model, |
|
| Where |
"Generate a video: a cozy coffee shop on a rainy evening, camera slowly moving towards the window"
"Make a video from this image as the first frame: https://… , the character turns and smiles"
"Check my video generation status and download it when ready"
Test the server with the official MCP Inspector:
npx @modelcontextprotocol/inspector uv --directory . run server.pyPython · MCP Python SDK · httpx (async) · Replicate HTTP API
MIT
Проверить статус генерации видео по ID и получить ссылку, когда оно готово.
Args: prediction_id: ID, который вернул generate_video.
| Name | Required | Description | Default |
|---|---|---|---|
| prediction_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does convey the essential behavior — this is a status probe whose useful output only materializes when generation completes — but it says nothing about possible status values, whether repeated polling is safe/rate-limited, or behavior on an invalid or expired ID.
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 plus a one-line Args note; the purpose and the outcome are front-loaded and nothing is redundant.
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 single-parameter, read-style polling tool with an output schema covering return values, the description is nearly sufficient: purpose, parameter origin, and result are all covered. Only polling/status semantics are missing.
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 0%, so the single parameter is undocumented in the schema, but the description compensates by explaining the parameter's origin and meaning: it is the prediction identifier returned by generate_video. That is exactly the semantics an agent needs to pass the right value.
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 status of a video generation job by ID — and adds the outcome (a link once it is ready). It hints at ordering by saying the ID comes from generate_video, but never distinguishes itself from download_video, which is the natural next step.
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?
The Args note 'ID, который вернул generate_video' establishes the precondition and workflow position: call this after generate_video using the returned prediction_id. It gives no exclusions, no polling cadence, and no pointer to download_video for retrieving the finished file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Скачать готовое видео на компьютер (по умолчанию в папку Videos/video-mcp).
Args: video_url: Ссылка на видео из generate_video или check_video. filename: Необязательно. Имя файла, например "fox.mp4".
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | ||
| video_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It usefully discloses the default save location, but says nothing about overwrite behavior when the file already exists, permissions, or whether the download is reversible — notable gaps for a tool that writes to disk.
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?
Short, front-loaded, and the Args block maps directly to the schema with zero filler. The parenthetical default-path note earns its place.
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?
With only two parameters, both documented, an output schema covering return values, and the default destination disclosed, the agent has enough to invoke it correctly. The missing piece is collision/overwrite behavior on an existing file.
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%, so the description must compensate, and it does: it explains both parameters, notes filename is optional and shows a concrete example ('fox.mp4'), and identifies the valid source of video_url. Only format expectations for video_url (URL vs. ID) are left unstated.
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 ('Скачать готовое видео на компьютер') plus a concrete default destination folder. Sibling differentiation is implicit rather than explicit: it names generate_video and check_video only as URL sources, not as tools to prefer for other tasks.
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 a clear precondition — the video_url must come from generate_video or check_video — which tells the agent where this tool fits in the workflow. It does not state when not to use it or what to do on failure, so no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сгенерировать короткое видео по текстовому описанию.
Args: prompt: Подробное описание сцены (лучше на английском), например "a red fox running through snowy forest, cinematic, slow motion". image_url: Необязательно. Ссылка на картинку, которая станет первым кадром. model: Необязательно. Модель Replicate в формате "владелец/название". По умолчанию minimax/video-01.
Генерация обычно занимает 1–5 минут. Если видео не успело сгенерироваться, инструмент вернёт ID — затем используйте check_video.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| prompt | Yes | ||
| image_url | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does disclose the key non-obvious traits: the 1–5 minute latency and the async fallback that returns an ID instead of a video. It also names the default model. It doesn't mention cost, rate limits, or what happens on generation failure, so it is not exhaustive.
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 purpose statement is front-loaded and the Args block is tight, with each parameter getting one useful line. The docstring-style parameter block repeats parameter names already in the schema, which is mild overhead, but the added semantics justify the space.
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 needn't be spelled out, and the description covers the one behavioral quirk an agent must know: the ID-returning async path plus the pointer to check_video. For a three-parameter, one-required generation tool this is close to complete, missing only failure/cost expectations.
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%, so the description must compensate, and it does: prompt is documented with an example string and a language recommendation, image_url is explained as the first frame, and model is documented as owner/name format with a stated default (minimax/video-01). The only gap is that image_url doesn't state whether it must be publicly accessible or what sizes/formats are accepted.
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 opening sentence names a specific verb+resource ('Сгенерировать короткое видео по текстовому описанию') and adds the qualifier 'короткое', so the agent knows exactly what is produced. It is clearly distinguishable from check_video and download_video, and the final sentence explicitly routes to check_video for the polling step.
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?
The description gives a clear usage context: generation takes 1–5 minutes, and if the video isn't ready the tool returns an ID that must then be passed to check_video. That is real when-to-use routing. It lacks explicit when-not-to-use guidance (e.g., cost, concurrent generation limits), so it falls short of a 5.
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_videodownload_videogenerate_videoScored across 3 tools
Each tool maps to a distinct step in an asynchronous pipeline: creation (generate_video), polling (check_video), and retrieval (download_video). There is no overlap in purpose, and the descriptions explicitly chain them (generate returns an ID for check_video, check_video returns a URL for download_video).
All three names follow a strict verb_noun pattern (generate_video, check_video, download_video) with a shared 'video' resource noun. Fully predictable and consistent.
Three tools are minimal but each earns its place in the async generation workflow, with no bloat. It is at the low end of the scale, so slightly thin for anything beyond single-video generation.
The generate → poll → download lifecycle is fully covered, so an agent can complete the core task end to end. Minor gaps exist: no cancel/delete for a stuck prediction, no way to list past predictions, and no model discovery tool.
Turn Claude into a creative studio: DNA-locked characters, images, video, voiceover — 55 tools.
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
Publish and schedule videos to TikTok, YouTube Shorts, Instagram, Facebook, LinkedIn, Pinterest, Bluesky, Threads and X from Claude, Cursor or any MCP client. Upload once, post everywhere, track views in unified analytics, and retry failed posts. Official platform APIs only, free plan available. Docs: https://docs.multi-upload-tool.com/mcp
Generate images, video, and audio with Glif's media-generation agent
