Chutes Media MCP lets coding agents discover, describe, and invoke Chutes media models to generate or edit media assets saved directly into the workspace.
List available Chutes models for image, video, music, and speech, with optional kind or text filtering.
Fetch a model’s live cords and input schemas before generation, including editing cords like img2img and inpaint.
Generate image, video, music, or speech assets using schema-validated payloads.
Edit existing images when supported by a model, referencing workspace files.
Save generated assets under a configurable output directory, defaulting to ./assets/chutes/<kind>/.
Return the saved asset path and write a provenance sidecar with model, cord, params, and schema hash.
Preserve existing files unless overwrite is explicitly set, with workspace-contained path handling.
Automatically retry cold-start models and emit progress updates for long video or music jobs.
Use the same capabilities through either the MCP server or the chutes-media CLI.
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., "@chutes-media-mcp generate an image of a futuristic city skyline"
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.
Generate image, video, music, and speech through Chutes from any coding agent, with the asset saved straight into the project you are working on.
Chutes Media MCP is a Model Context Protocol (MCP) server and command-line interface (CLI) that give coding agents access to Chutes media models. It ships as an MCP server on standard input/output (stdio), a thin CLI for agents without MCP support, and a bundled Agent Skill for the describe-then-generate workflow.
Instead of hardcoding a payload per model, the server fetches the model's live schema and validates each request before spending a GPU call, then writes the asset and a provenance record into your workspace. It works with Claude Code, Cursor, Cline, Windsurf, Codex, OpenCode, and Claude Desktop.
This is an independent community project. It is not affiliated with, sponsored by, or endorsed by Chutes.
Run the server from npm without installing it globally:
npx -y chutes-media-mcpInstall it globally to put both binaries on your path:
npm install -g chutes-media-mcpRegister the server with Claude Code:
claude mcp add chutes-media --env CHUTES_API_KEY=cpk_your_key -- npx -y chutes-media-mcpFor Cursor, Cline, Windsurf, OpenCode, and Claude Desktop, add the mcpServers entry documented in
docs/mcp-and-cli.md. Running from GitHub instead of npm is supported with
npx -y github:TheStreamCode/chutes-media-mcp. Upgrading from 1.x? See
docs/migration-2.0.md.
Related MCP server: ComfyUI MCP Server
Create a Chutes API key at chutes.ai and register the server as shown under Install.
Ask your agent for an asset: "Generate a cinematic hero image of a misty mountain range and save it in this project."
The agent discovers a suitable model, reads its live schema, validates the payload, and saves the
result under assets/chutes/image/. The returned path is ready to reference from your code.
The same describe-then-generate flow is available from a shell through the chutes-media CLI. See
docs/mcp-and-cli.md for the tool reference, CLI examples, and image editing.
Four media kinds (image, video, music, speech), plus image editing when a model exposes an edit
cord such as img2img or inpaint.
Live model contract: cords and input schema are fetched at runtime, never hardcoded.
Payload validation against the live schema before any GPU call is made.
Workspace-contained file access; existing assets survive unless overwrite is explicitly set.
A provenance sidecar per asset with model, cord, params, and schema hash.
Automatic cold-start retry with backoff for models that scale to zero.
Progress updates for long video and music jobs.
One shared core, so the MCP server and the CLI behave identically.
Node.js 20.3 or newer for the published server and CLI. Node.js 20 is end-of-life; use Node.js 22 or 24 LTS in production.
A Chutes API key.
Contributors using the locked toolchain need Node.js ^20.19.0, >= 22.13.0, or >= 24.
Variable | Required | Default | Purpose |
| Yes | none | Chutes API key. Read from the environment; never written to disk. |
| No |
| How the key is sent in |
| No |
| Management API base URL. HTTPS is required except for loopback development; custom endpoints never receive the Chutes API key. |
| No |
| Output directory inside the agent's working directory. A |
| No |
| Warm models up before invoking them. Set to |
| No |
| Retries when a cold model returns |
| No |
| Base backoff between cold-start retries; it grows per attempt. |
| No |
| Maximum response or local input asset size kept in memory. The maximum is |
| No |
| How often progress heartbeats are emitted while a call blocks. |
| No |
| When |
| No |
| Write a |
Generated assets are saved under ./assets/chutes/<kind>/, relative to wherever the agent runs, so
they land inside the project. Output traversal and symlink escapes are rejected, and existing files
are preserved unless overwrite is enabled.
The API key is read from CHUTES_API_KEY and kept in memory. Credential-bearing requests go only to
HTTPS Chutes hosts, remote asset URLs are screened against private-network destinations, and file
access is contained to the workspace. Query strings and fragments are removed from network-error
messages so signed asset URLs do not end up in logs. The project collects no telemetry. See
SECURITY.md for reporting.
The key is missing, invalid, or sent with the wrong authentication scheme. Confirm CHUTES_API_KEY
is set for the process that launches the server, then set CHUTES_AUTH_SCHEME to bearer or raw,
whichever differs from the current value.
The model is scaled to zero and Chutes has no instance ready. The server retries automatically;
raise CHUTES_COLD_START_RETRIES and CHUTES_COLD_START_BACKOFF_MS if the delay is too short, or
pick another model of the same kind.
The live model schema changed or the parameter name is wrong. Call describe_media_model again and
rebuild the payload from the current schema. CHUTES_ALLOW_UNKNOWN_PARAMS=true is a temporary
workaround, not a fix.
Every input and output path must resolve inside the current workspace, and an existing file is not
replaced implicitly. Pass the explicit overwrite option (or --overwrite in the CLI) after
checking the target path.
Requirements: Node.js ^20.19.0, >= 22.13.0, or >= 24 with npm.
git clone https://github.com/TheStreamCode/chutes-media-mcp
cd chutes-media-mcp
npm ci
npm run check
npm run verify:mcp
npm run release:checknpm run check runs the format check, lint, type check, coverage tests, and the build.
npm run verify:mcp starts the built stdio server with a placeholder key and validates the MCP
handshake, the instructions and the three tool definitions without calling Chutes. npm run release:check keeps package.json, CHANGELOG.md, CITATION.cff and server.json on the same
version.
CONTRIBUTING.md covers the Windows path caveat and the opt-in live tests.
Ask usage questions in GitHub Discussions,
report reproducible defects in GitHub Issues,
and report vulnerabilities privately as described in SECURITY.md.
See CONTRIBUTING.md. Pull requests must pass the required CI checks.
MIT — see LICENSE. Third-party notices are in NOTICE.
Maintained by Michael Gasperini (Mikesoft). If this project is useful to you, consider sponsoring its maintenance.
Fetch a model's live cords and input schemas so you can compose a valid request. ALWAYS call this before generate_media for an unfamiliar model. Returns every cord (e.g. generate, and img2img/inpaint when present) with its required fields, types, defaults and a minimal example payload.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name/slug, e.g. owner/model-slug. |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| cords | Yes | |
| model | Yes | |
| tagline | No | |
| invokeBaseUrl | No | |
| supportsEditing | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the description only needs to add context. It does so by describing the payload content (every cord with required fields, types, defaults, minimal example), which helps the agent plan the follow-up call.
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?
Three tight sentences with the call-before-use instruction front-loaded and no redundant restatement of the name or title.
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 one-parameter read tool with full schema coverage and an output schema, the definition supplies the missing piece — when to call it and what the return payload contains. Nothing needed for correct invocation is absent.
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?
The single 'model' parameter has 100% schema description coverage including the 'owner/model-slug' format, so the schema does the work. The description adds nothing about the parameter itself, which is the baseline 3 case.
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 ('model's live cords and input schemas') with the goal ('compose a valid request'). It is clearly distinguishable from list_media_models (listing) and generate_media (execution).
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?
Explicitly instructs 'ALWAYS call this before generate_media for an unfamiliar model,' giving a clear trigger condition. It doesn't mention when list_media_models is the better entry point, so the sibling routing is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a generation and save the asset into the workspace. params is the payload you composed from describe_media_model. For editing, params may reference workspace file paths (e.g. image, mask) which the server reads and encodes. The asset is saved under output_dir (default ./assets/chutes//) and the saved path is returned. Long video/music jobs block with progress updates.
| Name | Required | Description | Default |
|---|---|---|---|
| cord | No | Operation/cord (e.g. img2img); defaults to the primary one. | |
| kind | Yes | ||
| model | Yes | ||
| params | Yes | Payload matching the cord's input schema. | |
| filename | No | ||
| overwrite | No | Explicitly replace an existing asset and sidecar. | |
| output_dir | No | Output directory relative to CWD. | |
| timeout_ms | No |
| Name | Required | Description |
|---|---|---|
| cord | Yes | |
| cost | No | |
| kind | Yes | |
| path | Yes | |
| bytes | Yes | |
| model | Yes | |
| durationMs | Yes | |
| schemaHash | No | |
| contentType | Yes | |
| provenancePath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable context beyond the destructive=true/openWorld=true annotations: default save location, that the saved path is returned, that the server reads and base64-encodes referenced workspace files, and that long video/music jobs block with progress updates. It does not explain what happens when an asset already exists (overwrite semantics live only in the schema) or any rate/cost limits.
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?
Four dense sentences, front-loaded with the core action and outcome, then parameter guidance, then output location, then long-job behavior. No filler or repetition of schema fields.
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?
Given an output schema exists and annotations cover the safety profile, the description supplies the essential operational context: the describe_media_model dependency, file-path based editing, where results land, and blocking behavior for long jobs. It stops short of covering overwrite/conflict behavior and timeout handling for a destructive tool.
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?
With only 50% schema description coverage, the description meaningfully compensates for the most important parameters: it explains that `params` is a cord-specific payload sourced from describe_media_model and may reference workspace paths, and it clarifies `output_dir` semantics with a default. Other params (cord, filename, overwrite, timeout_ms, kind, model) remain unexplained in the description.
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 outcome: run a generation and save the resulting asset into the workspace. By naming `params` as the payload composed from describe_media_model, it clearly positions itself as the execution step versus the sibling list/describe tools.
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?
Explicitly tells the agent to compose `params` using describe_media_model first and notes that editing workflows may pass workspace file paths for the server to read and encode. It gives clear context but does not state when *not* to use it or compare against the siblings directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Chutes media-generation models (image / video / music / speech), optionally filtered by kind or a free-text query. Use this to discover a model, then call describe_media_model before generate_media.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | No | Free-text filter on the model name. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is fully covered. The description adds the useful discovery-role context, but says nothing about result volume, default page size, ordering, or what happens when limit is omitted — the practical behaviors an agent still needs to guess at.
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 sentences, zero padding, with the capability statement front-loaded and the routing advice second. Every clause carries 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?
An output schema exists, so return values need no explanation, and the sibling workflow is spelled out. The only gap is pagination/default-limit behavior, which matters for a list tool with a 200-item cap but is not covered anywhere in the description.
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 only 33%, so the description must carry weight, and it does: it explains that kind narrows to the four media types and that query is a free-text filter applied to discovery. Only limit is left unaddressed, though its bounds are self-documenting in 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?
States a specific verb (List) and resource (Chutes media-generation models), and enumerates the domains covered (image / video / music / speech). It is immediately distinguishable from describe_media_model, which it names as a separate, narrower 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?
Gives an explicit workflow: discover a model here, then call describe_media_model, then generate_media. This tells the agent both when to use this tool and which sibling to reach for next, leaving nothing to inference.
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.
describe_media_modelgenerate_medialist_media_modelsScored across 3 tools
The three tools form a clear discovery-to-execution pipeline: list models, inspect a model's schema, then generate. Each has a distinct purpose and the descriptions explicitly guide sequencing, leaving little room for misselection.
All tool names use consistent snake_case with verb-led phrasing: list_media_models, describe_media_model, generate_media. The pattern is predictable and readable throughout.
Three tools are well-scoped for a media-generation workflow: discovery, schema inspection, and generation. Each tool earns its place, and the set avoids unnecessary surface area.
The core workflow is covered: list models, inspect live schemas, and generate/save assets with progress updates. Minor gaps exist around asset management or job cancellation/status, but the main generation lifecycle is complete enough for agents to work with.
Generate images, videos, voiceovers, and captions from a chat prompt.
Create AI images and videos, manage projects and credits, and use workspace campaign context.
Generate reproducible image, video, and audio assets with leading models and your own provider keys.
Generate AI images, videos and music from your AI client.
