This server gives authenticated RunAPI access to the retired Luma model line, primarily for checking existing (historical) tasks.
login — authenticate through a browser PKCE flow, saving the API key to ~/.config/runapi/config.json; force re-runs login when credentials already exist locally.
get_task — fetch the current status and latest result payload for an existing Luma task using its task_id (optional action defaults to modify_video).
check_pricing — look up pricing for the Luma line, though the README states it returns no supported model because the line is retired.
modify_video — the schema exposes task creation, but the README says this model was retired on 2026-10-14; new requests return HTTP 410 before task creation or balance deduction, so only pre-existing tasks can be queried.
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., "@@runapi.ai/luma-mcp modify video at https://example.com/vid.mp4 to apply a cinematic look"
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/luma-mcp is a focused Model Context Protocol server for the Luma model line on RunAPI.
It gives MCP-compatible assistants direct access to 0 endpoints and 0 model variants without loading the full RunAPI catalog.
Use this per-model server when an agent should stay scoped to Luma. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.
luma-modify-video was retired on 2026-10-14T00:00:00Z. New requests return HTTP 410 before task creation or balance deduction. Existing tasks can still be queried. This model ID is not mapped to another model.
Related MCP server: kling-mcp
Add it to Claude Code:
claude mcp add luma -s user -- npx -y @runapi.ai/luma-mcpUse project scope when the server should be shared with a repository:
claude mcp add luma -s project -- npx -y @runapi.ai/luma-mcpCodex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:
{
"mcpServers": {
"luma": {
"command": "npx",
"args": ["-y", "@runapi.ai/luma-mcp"]
}
}
}No models in this package accept new tasks. check_pricing returns no supported model. For historical task lookup, 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 |
| get_task | Yes | Fetch the current status and latest payload for an existing task. |
| check_pricing | No | Returns no supported model because this model line is retired. |
Luma covers 0 model variants across 0 endpoints. Each tool accepts the models listed for it:
Tool | Models |
Model availability can change between releases. Use check_pricing or the Luma model page for the current catalog view.
Query an existing task with get_task. New requests for this retired model return HTTP 410.
Check the status of my existing Luma task with RunAPI.The assistant calls get_task with the task id and returns its status and available result.
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 |
Luma 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 luma 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?
With no annotations, the description carries the full behavioral burden. It implies a read-only lookup but never states that it is non-mutating, whether auth is required, whether results are cached or subject to rate limits, or what the returned pricing represents (per-token, per-call, currency).
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; it is efficient, though arguably too terse for a tool with two parameters and no annotations to lean on.
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 and no annotations, so the description is the only source of context, and it omits what the returned pricing data looks like and under what conditions it applies. For a simple lookup this is minimally adequate but leaves real 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 100% and both parameters are optional with documented defaults, so the baseline is 3. The description's mention of 'the luma model line' loosely hints at the model parameter but adds no syntax, format, or default behavior beyond what the schema already documents.
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), and scopes it to the luma model line, which separates it from the unrelated siblings get_task and login. However, the fixed scope to 'the luma model line' sits awkwardly with a schema that accepts an arbitrary model slug, so the intended breadth of the tool is slightly ambiguous.
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 alternatives, no preconditions, and no mention that pricing lookups may require authentication (a sibling 'login' tool exists). The agent is left to infer all usage context.
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 luma task.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Asynchronous endpoint the task was created on. Defaults to the line's only asynchronous endpoint. | |
| task_id | Yes | Task id returned when the task was created. |
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 read semantics and that the payload returned is the 'latest result', implying results may not exist yet. But it omits auth requirements, whether repeated calls are safe, and how status values should be interpreted.
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 tight sentence that front-loads the verb and resource with no wasted words. Nothing redundant or padded.
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?
No output schema and no annotations, so the description is the only place an agent could learn what the returned status/result payload looks like or when polling should stop. For a status-polling tool it leaves the workflow and return shape underspecified.
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 parameters (task_id, action) are already documented in the schema, including the enum and its default behavior. The description adds no parameter-level meaning, so the 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 (Fetch) and resource (luma task status + latest result payload), which is unambiguous. However it does not differentiate itself from any sibling — the siblings (login, modify_video, check_pricing) don't overlap, so there is nothing to contrast against, which keeps it short 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 when-to-use guidance is given: nothing says this is the polling tool to call after modify_video returns a task id, nor whether it should be called once or repeatedly until a terminal state. 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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0check_pricing1 field changedInput schema / properties / action / enumRemoved value: -[
- "modify_video"
-]modify_videov0.2.0check_pricing2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / model / enumRemoved value: -[
- "luma-modify-video"
-]get_task1 field changedInput schema / additionalPropertiesRemoved value: -falsemodify_video8 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / callback_url / descriptionAdded value: +"Declared type: string."Input schema / properties / model / enumRemoved value: -[
- "luma-modify-video"
-]Input schema / properties / poll_interval_ms / maximumAdded value: +9007199254740991Input schema / properties / prompt / descriptionAdded value: +"Declared type: string."Input schema / properties / source_video_url / descriptionAdded value: +"Declared type: string."Input schema / properties / timeout_ms / maximumAdded value: +9007199254740991Input schema / properties / watermark / descriptionAdded value: +"Declared type: string."v0.1.7get_task1 field changedInput schema / properties / action / descriptionPrevious value: -"Endpoint the task was created on. Defaults to the line's only endpoint."New value: +"Asynchronous endpoint the task was created on. Defaults to the line's only asynchronous endpoint."modify_video5 fields changedInput schema / properties / callback_urlAdded value: +{
+ "type": "string"
+}Input schema / properties / prompt / typeAdded value: +"string"Input schema / properties / source_video_url / typeAdded value: +"string"Input schema / properties / watermarkAdded value: +{
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "prompt",
+ "source_video_url"
+]v0.1.6loginv0.1.4check_pricingget_taskmodify_videoScored across 3 tools
The three tools have clearly distinct purposes: pricing lookup, task status retrieval, and authentication. There is no overlap or realistic chance of an agent confusing one for another.
check_pricing and get_task follow a consistent verb_noun snake_case pattern, and login is also snake_case but is a bare verb with no noun. The minor deviation is conventional and still readable.
Three tools is borderline thin for a model-serving MCP; one slot is consumed by login and another by pricing, leaving only a single task-status tool. A minimal client could work with this, but it feels under-scoped.
The surface has a major dead end: get_task retrieves results but no tool submits or creates a Luma task, so the core generate/run workflow cannot be initiated. Pricing and login are covered, but the primary lifecycle operation is missing.
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Create AI images, video, and audio, quote generation costs, and edit Sequencer projects.
Run multi-step AI pipelines for video, image, audio and text: upload media, run, poll results.
