Luma MCP is the Model Context Protocol layer over Dream Machine, and Luma now ships an official server for it. Point an assistant at that server and the Ray video models and Photon image models stop being a REST endpoint you script by hand and become tools the model can call on its own. The repo is lumalabs/luma-api-mcp. If you already use MCP to hand Claude or Cursor access to your own systems, the same pattern that powers connecting Claude and ChatGPT to private business data now works for generating footage.
The practical difference is small but real. Without MCP you write a script that posts to the Dream Machine API, polls a job id, and downloads a file. With MCP you say "make a 9 second 1080p shot of a car pulling into a wet parking lot" and the assistant does the posting and the polling for you, then hands back a URL. Nothing about the underlying model changes. What changes is who writes the glue.
This piece covers what the Luma MCP server actually exposes, how to wire it up, what a session costs, and the places where a single-vendor MCP server runs out of room. If you are coming at this from the developer side, the setup is close to what you would already do for an AI API with Claude Code integration.
What the server exposes
Both the official server and the widely used community build, bobtista/luma-ai-mcp-server, wrap Dream Machine API v1 and expose a similar surface. The community version publishes ten tools, which is a useful map of what an assistant can actually do once the server is connected:
- ping and get_credits - connection check and remaining balance
- create_generation - text to video, image to video, and keyframe generation
- get_generation and list_generations - poll job status, browse history
- delete_generation - clean up a run
- upscale_generation - raise resolution on a finished clip
- add_audio - attach generated audio to a video
- generate_image - Photon stills, with image, style, and character references
- get_camera_motions - list the supported camera move keywords
Model coverage on the community server is ray-2 as the default, ray-flash-2 for speed, ray-1-6 as legacy, plus photon-1 and photon-flash-1 for stills. The official Luma repo tracks the current Ray and Photon lineup more closely, which matters because Luma has shipped several Ray 3 point releases since. Either way, the tool surface reads like a thin, honest wrapper over the REST API rather than a re-imagining of it, which is the correct design for programmatic video generation platforms.
Wiring it into a client
Setup is a config block and an API key. Grab a key from the Luma API dashboard, then add an entry to your MCP client config. On Claude Desktop that file lives at %APPDATA%\Claude\claude_desktop_config.json on Windows or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS:
{
"mcpServers": {
"luma": {
"command": "uv",
"args": ["run", "--project", "/path/to/server", "-m", "luma_ai_mcp_server"],
"env": { "LUMA_API_KEY": "your-key" }
}
}
}
The server talks stdio, so it runs as a local child process of the client and dies with it. That is fine on a laptop and awkward on a server, and it is one of the reasons agent tooling has been drifting toward hosted, remote MCP endpoints over the past year, a shift covered in more depth in how AI agents are changing the way creators research and build.
What a session costs
Dream Machine API billing is pay as you go and separate from the app subscription, which trips people up. A 720p five second clip lands around $0.30. A 1080p ten second clip is roughly $3.60. HDR output is priced at 2x, and HDR plus EXR at 3x. Credits bought inside the Dream Machine app do not transfer to the API, and monthly credits do not roll over, so an assistant left looping on a prompt can spend real money quickly. Anyone running this unattended should read up on AI generation APIs with spend limits before handing an agent a key.
The consumer tiers moved in March 2026 to Plus at $30, Pro at $90, and Ultra at $300 a month, framed as usage multipliers rather than fixed credit counts. None of that touches the API meter. If you are budgeting for MCP work, budget the API line only.
The upside of the MCP framing is that cost becomes visible mid-conversation. get_credits is one of the exposed tools, so an assistant can check the balance before it fires a batch, which is more than most SDK wrappers bother to do. That kind of self-checking loop is a genuine improvement over the fire-and-hope pattern common across AI video generators compared in 2026.
The constraints worth knowing before you build
The server inherits every limit of the underlying API, and a few of them shape what you can build on top. They are worth reading before you design anything around them, the same way you would check the constraints on any programmatic video generation platform.
- Duration is fixed. Generations are 5s or 9s. There is no arbitrary length parameter; longer pieces come from extension and stitching.
- Upscaling is one-shot. Each generation can be upscaled once. Plan the target resolution before you commit.
- Resolution ladder is discrete. 540p, 720p, 1080p, and 4k, nothing between.
- Local transport. The stdio server runs where the client runs, which complicates CI and shared team setups.
None of these are defects, they are just the shape of the tool. The one that bites hardest in practice is single-vendor scope: a Luma MCP server speaks Luma. If a shot list calls for Ray on the establishing shots and something else on the dialogue coverage, you are adding a second server, a second key, and a second set of tool names to the same context window. Teams comparing options here usually end up reading about accessing Google Veo via API alongside the Luma docs.
Context cost is the quiet tax. Every connected MCP server injects its tool definitions into the model's context on every turn. Two or three video servers plus your normal tooling adds up fast, and the assistant starts guessing which create_generation it meant. Keeping the surface small is worth more than it sounds, particularly on longer jobs like multi-shot storytelling with consistent characters.
Community servers and the wrapper layer
Beyond the official repo there is a small ecosystem: bobtista's Python server, an AceDataCloud build that routes through its own API, a Smithery listing, and no-code bridges from Zapier and viasocket. The wrappers are convenient and they add a hop, a second bill, and a second point of failure. For anything production shaped, the official server or a direct API integration is the safer footing, the same conclusion most people reach when they generate videos with Kling via API.
Pick a community build when it exposes something the official one does not, such as the audio and camera-motion helpers, and when you have read the source. Pick the official one when you want the current model lineup without waiting on a maintainer.
FAQ
Is there an official Luma MCP server?
Yes. lumalabs/luma-api-mcp is maintained by Luma and covers Ray for video and Photon for images. Several community servers exist as well, and they generally track the same Dream Machine API v1 surface documented in the Veo 3.1 video API examples and pricing breakdown for the competing stack.
Do I need a paid Luma plan to use it? You need an API key with credit on it. API billing is separate from the Dream Machine app subscription, and credits do not move between the two.
Can one MCP server cover more than one video model? Not the vendor ones. Luma's server speaks Ray and Photon only, so a multi-model shot list means running a second server, a second key, and a second tool namespace inside the same context window. The alternative is a hosted endpoint that fronts several vendors at once, such as a single MCP endpoint that also reaches Veo 3.1 and Kling alongside Dream Machine, which keeps the tool surface flat as the model list grows.
How long can a generated clip be? Five or nine seconds per generation. Longer sequences are built by extending or interpolating between generations, then joining the results.
What does a typical clip cost through the API?
Roughly $0.30 for 720p at five seconds and around $3.60 for 1080p at ten seconds, with HDR at 2x. The exposed get_credits tool lets an assistant check the balance before it spends, which is a habit worth enforcing on any node-based AI platform with an API too.
Can it run on a server rather than a laptop? The stdio servers are designed to run as a child process of the MCP client. Remote deployment means fronting them yourself or choosing a hosted remote MCP endpoint.
Wrapping up
The Luma MCP server is a clean piece of plumbing. It does not make Ray better, it removes the script you would otherwise write, and it gives an assistant a way to check its own credit balance before it burns through a budget. For a single-vendor workflow that is most of what you want, and it beats hand-rolling the polling loop yourself the way people did before AI node editors with APIs made the pattern common.
The moment the shot list crosses vendors, the calculus changes and the question stops being "which MCP server" and starts being "how many tool namespaces can this context window carry." That is worth thinking about before you connect the third one, and it is the same tradeoff that shows up across AI workflow platforms with APIs.