This server enables AI agents to generate and manage videos using Runway models on RunAPI, with the following capabilities:
Generate videos from text (text_to_video): Create a Runway text-to-video task by providing a prompt, duration (5 or 10 seconds), output resolution (720p or 1080p), aspect ratio (16:9, 9:16, 1:1, 4:3, 3:4), and optionally a first frame image URL.
Extend existing videos (extend_video): Create a Runway extend-video task referencing an existing task, with configurable output resolution (720p or 1080p).
Poll task status (get_task): Fetch the current status and latest result payload (including output URLs) for a previously created task using its task ID.
Check pricing (check_pricing): Look up the current pricing snapshot for a specific endpoint (extend_video or text_to_video) — no API key required.
Flexible execution control: All creation tools support a wait flag to block until the task completes or return immediately with a task ID, plus configurable timeout_ms and poll_interval_ms for fine-tuned polling behavior.
All task creation tools require a RunAPI API key; check_pricing does not.
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., "@runway-mcp create a 5-second video of a cat dancing"
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.
@runapi.ai/runway-mcp is a focused Model Context Protocol server for the Runway model line on RunAPI.
It gives MCP-compatible assistants direct access to 2 endpoints and 1 model variant without loading the full RunAPI catalog.
Use this per-model server when an agent should stay scoped to Runway. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.
Related MCP server: kling-mcp
Add it to Claude Code:
claude mcp add runway -s user -- npx -y @runapi.ai/runway-mcpUse project scope when the server should be shared with a repository:
claude mcp add runway -s project -- npx -y @runapi.ai/runway-mcpCodex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:
{
"mcpServers": {
"runway": {
"command": "npx",
"args": ["-y", "@runapi.ai/runway-mcp"]
}
}
}check_pricing works before sign-in. For task creation and status polling, ask your assistant to call the login tool. It opens a browser login and saves credentials to ~/.config/runapi/config.json, the same file used by runapi login.
Headless and CI hosts can still set RUNAPI_API_KEY before starting the MCP host.
Ready-made examples are in examples/ for Claude, Cursor, Windsurf, VS Code, and Roo Code.
Tool | Auth | Purpose |
| Yes | Create a Runway extend video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Create a Runway text to video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Fetch the current status and latest payload for an existing task. |
| No | Look up current pricing for a Runway model and endpoint. |
Runway covers 1 model variant across 2 endpoints. Each tool accepts the models listed for it:
Tool | Models |
|
|
|
|
Model availability can change between releases. Use check_pricing or the Runway model page for the current catalog view.
Ask your assistant in natural language; it can inspect pricing, create the task, and return the task id plus output URLs.
Run a Runway extend video task with RunAPI.The assistant can call check_pricing, then extend_video, and return the task id, status, and output URLs.
Create the task but don't wait for it to finish.The assistant calls the create tool with wait: false and returns the task id. Check on it later with get_task.
Check current Runway pricing, then create the task if it matches my request.The assistant calls check_pricing and can link to the Runway model page for the canonical catalog entry.
The server resolves auth in this order:
RUNAPI_API_KEY environment variable, useful for headless and CI hosts
~/.config/runapi/config.json, created by the MCP login tool or runapi login
No key, which still allows check_pricing
The config file is normally managed by login. A pre-provisioned headless config can use:
{
"apiKey": "your_runapi_key"
}Do not commit real API keys.
Resource | URL |
Runway model page | |
npm package | |
GitHub repository | |
RunAPI MCP overview | |
RunAPI docs |
Licensed under the Apache License, Version 2.0.
Look up RunAPI pricing for the runway model line.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model slug. Defaults to the line's primary model. | |
| action | No | Endpoint name. Defaults to the endpoint that offers the model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Look up' implies a read-only operation, but the description says nothing about whether pricing is live or cached, whether auth is required, or what the response contains. For a zero-annotation tool this is a substantial gap.
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?
A single, front-loaded sentence with no filler. The verb and resource lead immediately, and nothing is wasted.
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 no annotations and no output schema, the description is the only place behavioral and return-value context could live, and it is thin. The parameters are covered by the schema, but an agent gets no sense of what pricing data comes back or under what constraints the lookup succeeds.
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 both the 'model' and 'action' parameters are already fully documented in the schema, including their default behavior. The description's mention of the 'runway model line' loosely maps to the model parameter but adds no syntax, format, or enum detail beyond the schema. 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 ('look up') and resource ('RunAPI pricing') scoped to the 'runway model line'. This clearly distinguishes it from siblings (extend_video, text_to_video, get_task, login), none of which relate to pricing, though 'runway model line' is slightly ambiguous without further definition.
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 no when-to-use guidance, no mention of prerequisites (e.g., authentication), and no conditions that would steer an agent toward or away from this tool. It simply states what the tool is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Runway task on RunAPI (extend video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | Yes | Declared type: string. | |
| watermark | No | Declared type: string. | |
| timeout_ms | No | ||
| callback_url | No | Declared type: string. | |
| source_task_id | Yes | Declared type: string. | |
| poll_interval_ms | No | ||
| output_resolution | Yes | Declared type: string. Known values: "720p", "1080p". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the return shape (task id, status, output URLs), which hints at an async task model, but it never states auth requirements, cost implications, or how the wait/poll_interval_ms/timeout_ms/callback_url parameters affect behavior.
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, front-loaded sentences with no filler. It is efficient, though arguably so terse that the second sentence is doing all the informational work.
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 9 parameters, no annotations, and no output schema, the description should explain the async polling flow and where source_task_id comes from. It only covers return values, leaving the invocation workflow largely undocumented.
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 78%, close to the high-coverage baseline, so the schema does most of the documenting. The description adds nothing about any of the 9 parameters, leaving the polling and timeout semantics to the schema.
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 gives a concrete verb and resource ('Create a Runway task ... extend video') and names the platform, so the agent knows it initiates a video-extension task. It does not explicitly contrast with the sibling text_to_video, so the differentiation is only implied by the name.
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?
There is no guidance on when to use this tool versus text_to_video, nor any mention of prerequisites such as needing an existing source_task_id from a prior generation. The agent must infer the workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current status and latest result payload for a runway task.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Asynchronous endpoint the task was created on. | |
| task_id | Yes | Task id returned when the task was created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only fetch and says what is returned, but omits what status values exist, whether the result payload is absent while pending, idempotency, auth requirements, and any rate limits on polling.
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?
A single front-loaded sentence with no filler; the verb and the two returned artifacts come first. Nothing in it 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 two-parameter read tool with no output schema and no annotations, the description is minimally adequate but leaves the return semantics vague: what 'status' values look like and whether the result payload is null while the task is running are unstated.
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%, with both task_id and the action enum fully documented in the schema, so the baseline is 3. The description adds no syntax, format, or usage detail for either parameter beyond naming the task concept.
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 (fetch) and resource (current status plus latest result payload) for a named task type, so an agent can tell it is a polling/retrieval tool. It does not explicitly distinguish itself from siblings like extend_video or text_to_video, which create the tasks this one reads.
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?
There is no when-to-use guidance: no statement that this is the polling endpoint for tasks created by extend_video/text_to_video, no polling cadence advice, and no alternative to use instead. The workflow is only inferable from the 'action' enum hinting at the originating asynchronous endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Re-run browser login when the current credential comes from the local config file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the interactive browser flow and the file write side effect (config.json). However, it does not mention that it may overwrite existing credentials or that it could block waiting for user input, though these are implied.
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, well-structured sentence that front-loads the action ('Authenticate RunAPI') and provides necessary details without extraneous information.
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 login tool with one optional parameter and no output schema, the description covers the core purpose and side effect. It lacks an explicit statement that this is a prerequisite for other tools, but that is implied.
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% (the only parameter 'force' has a description). The tool description adds no additional meaning about parameters beyond the schema, so the baseline 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 clearly states the tool's purpose with a specific verb ('Authenticate'), target resource ('RunAPI'), method ('browser PKCE login flow'), and side effect (saving to config.json). It is distinct from sibling tools, none of which relate to authentication.
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 implies usage (to authenticate RunAPI) but does not explicitly say when to run it (e.g., before other RunAPI tools) or when to use the 'force' parameter. Since there are no alternative auth tools among siblings, 'vs alternatives' is not applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Runway task on RunAPI (text to video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | Yes | Declared type: string. | |
| watermark | No | Declared type: string. | |
| timeout_ms | No | ||
| aspect_ratio | No | Declared type: string. Known values: "16:9", "9:16", "1:1", "4:3", "3:4". | |
| callback_url | No | Declared type: string. | |
| duration_seconds | Yes | Declared type: integer. Known values: 5, 10. | |
| poll_interval_ms | No | ||
| output_resolution | Yes | Declared type: string. Known values: "720p", "1080p". | |
| first_frame_image_url | No | Declared type: string. |
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 usefully discloses the return shape (task id, status, output URLs) and that this spawns an asynchronous task, which is meaningful context. However, it omits permissions, cost/credit implications, and the fact that parameters like wait, timeout_ms, and callback_url make this a long-running or callback-driven operation.
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 tight sentences with no filler, and the core action is front-loaded before the return-value note. It is efficient, though very terse for a tool with 11 parameters.
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, so the description reasonably explains the return values, which helps. But for a complex 11-parameter async generation tool it omits auth needs, cost implications, and routing versus its siblings, leaving genuine gaps.
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 high at 82%, so the schema already documents most parameters, establishing a baseline of 3. The description names none of the 11 parameters and adds no syntax or format detail beyond the schema, so it does not exceed the baseline.
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 clear verb and resource: 'Create a Runway task on RunAPI (text to video).' The 'text to video' qualifier distinguishes it from the extend_video sibling, which implies extending existing footage. It stops short of explicitly naming the alternative, so it lands at 4 rather than 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?
The description gives no when-to-use context, no prerequisites, and no mention of alternatives. With siblings like extend_video and get_task present, an agent gets no signal about which tool applies to a given request. It only describes the artifact created, not when to reach for it.
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.2.0check_pricing2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / model / enumRemoved value: -[
- "runway"
-]extend_video10 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / callback_url / descriptionAdded value: +"Declared type: string."Input schema / properties / model / enumRemoved value: -[
- "runway"
-]Input schema / properties / output_resolution / descriptionAdded value: +"Declared type: string. Known values: \"720p\", \"1080p\"."Input schema / properties / output_resolution / enumRemoved value: -[
- "720p",
- "1080p"
-]Input schema / properties / poll_interval_ms / maximumAdded value: +9007199254740991Input schema / properties / prompt / descriptionAdded value: +"Declared type: string."Input schema / properties / source_task_id / descriptionAdded value: +"Declared type: string."Input schema / properties / timeout_ms / maximumAdded value: +9007199254740991Input schema / properties / watermark / descriptionAdded value: +"Declared type: string."get_task1 field changedInput schema / additionalPropertiesRemoved value: -falsetext_to_video15 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / aspect_ratio / descriptionAdded value: +"Declared type: string. Known values: \"16:9\", \"9:16\", \"1:1\", \"4:3\", \"3:4\"."Input schema / properties / aspect_ratio / enumRemoved value: -[
- "16:9",
- "9:16",
- "1:1",
- "4:3",
- "3:4"
-]Input schema / properties / callback_url / descriptionAdded value: +"Declared type: string."Input schema / properties / duration_seconds / descriptionAdded value: +"Declared type: integer. Known values: 5, 10."Input schema / properties / duration_seconds / enumRemoved value: -[
- 5,
- 10
-]Input schema / properties / duration_seconds / typePrevious value: -"number"New value: +"integer"Input schema / properties / first_frame_image_url / descriptionAdded value: +"Declared type: string."Input schema / properties / model / enumRemoved value: -[
- "runway"
-]Input schema / properties / output_resolution / descriptionAdded value: +"Declared type: string. Known values: \"720p\", \"1080p\"."Input schema / properties / output_resolution / enumRemoved value: -[
- "720p",
- "1080p"
-]Input schema / properties / poll_interval_ms / maximumAdded value: +9007199254740991Input schema / properties / prompt / descriptionAdded value: +"Declared type: string."Input schema / properties / timeout_ms / maximumAdded value: +9007199254740991Input schema / properties / watermark / descriptionAdded value: +"Declared type: string."v0.1.7extend_video5 fields changedInput schema / properties / callback_urlAdded value: +{
+ "type": "string"
+}Input schema / properties / prompt / typeAdded value: +"string"Input schema / properties / source_task_id / typeAdded value: +"string"Input schema / properties / watermarkAdded value: +{
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "output_resolution"
-]New value: +[
+ "source_task_id",
+ "prompt",
+ "output_resolution"
+]get_task1 field changedInput schema / properties / action / descriptionPrevious value: -"Endpoint the task was created on."New value: +"Asynchronous endpoint the task was created on."text_to_video5 fields changedInput schema / properties / callback_urlAdded value: +{
+ "type": "string"
+}Input schema / properties / first_frame_image_url / typeAdded value: +"string"Input schema / properties / prompt / typeAdded value: +"string"Input schema / properties / watermarkAdded value: +{
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "duration_seconds",
- "output_resolution"
-]New value: +[
+ "prompt",
+ "duration_seconds",
+ "output_resolution"
+]v0.1.6loginv0.1.0check_pricingextend_videoget_tasktext_to_videoScored across 5 tools
Each tool has a clearly distinct action and target: extend_video and text_to_video are separate generation modes, while get_task, check_pricing, and login serve unique supporting roles. No overlap in purpose is apparent from the descriptions.
Four of the five tools follow a verb_noun or verb_object pattern (extend_video, text_to_video, get_task, check_pricing). The lone login tool is a single verb, which is a minor but understandable deviation for an auth action.
Five tools is a well-scoped set for a focused Runway video-task integration, covering generation, status retrieval, pricing, and authentication without bloat. Each tool has a clear place in the workflow.
The surface covers task creation (two modes), status polling, pricing, and auth, but lacks obvious lifecycle operations such as cancel/delete task, list tasks, and other Runway generation modes like image-to-video. These are notable gaps for a server named after the broader Runway API.
130+ AI models for image, video, music, and audio — 18 model families, one RunAPI account.
Run multi-step AI pipelines for video, image, audio and text: upload media, run, poll results.
Generate images, videos and music with model discovery, cost estimates and asynchronous results.
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
