Runcomfy MCP

RunComfy MCP

MCP server for the RunComfy platform — Serverless API (ComfyUI), Model API, and Trainer API. Manage deployments, run hosted models, train LoRAs, and retrieve results from AI assistants like Claude, Cursor, and Windsurf.

Endpoint: https://mcp.runcomfy.com/mcp

Docs: docs.runcomfy.com/mcp

---

What it does

31 tools mirroring the RunComfy docs 1:1, across three products plus your account balance.

Serverless API (ComfyUI) — your own workflows on dedicated endpoints

Docs: docs.runcomfy.com/serverless

Model API — hosted catalog models, on demand

Docs: docs.runcomfy.com/model-apis

No deployment to manage and per-request billing. list_models browses the catalog by keyword or capability (category=image-to-video), get_model returns one model's input schema — property types, defaults, enums, and ranges — and run_model runs it. So an assistant can go from "make me a video" to a valid request without leaving the tools or guessing a parameter.

Entries also carry description, base_price_usd per price_unit, and a model_url to the model's page.

model_id is the identifier shown on the model's page at runcomfy.com/models, slashes included — e.g. blackforestlabs/flux-1-kontext/pro/edit. File inputs must be public HTTPS URLs.

Trainer API — datasets and AI Toolkit LoRA training

Docs: docs.runcomfy.com/trainer-apis

Typical flow: create a dataset → upload media and matching .txt captions → poll until READY → submit a job with an AI Toolkit YAML config → poll status → pull checkpoints from the result.

Because the server runs remotely it cannot read local files. Upload media it can reach over HTTP with upload_dataset_file_from_url, write captions inline with upload_dataset_text_file, and for local or >150 MB files use get_dataset_upload_urls and PUT the bytes to the signed URL yourself.

Account

One wallet funds all three products. get_balance reports what is left, in balance_usd for reading and balance_microdollars (millionths of a dollar) for exact threshold checks. It is served from api.runcomfy.net rather than mirrored per product, because there is only one figure to report.

Crossing between them

A trained LoRA runs without any deployment: pass its base model's model_id to run_model and the LoRA as an input, e.g. {"lora": {"path": "my_first_lora_3000.safetensors"}} — either a name from your LoRA Assets or a public URL such as a checkpoint from get_training_job_result. For a dedicated endpoint with chosen hardware, deploy it and use the Serverless tools instead.

---

Quick setup

Every client authenticates with a RunComfy API token from your Profile page. Two ways to supply it:

• API token header — works in any Streamable HTTP client. Simplest, and the only option for clients without a browser OAuth flow.
• Browser OAuth — no token in a config file. Supported by Claude.ai, Cursor, and local clients that register a loopback callback, such as Claude Code.

Claude Code

Token header (one command, nothing else to do):

claude mcp add --transport http runcomfy https://mcp.runcomfy.com/mcp --header "Authorization: Bearer YOUR_RUNCOMFY_TOKEN"

Or browser OAuth — omit the header, then run /mcp inside Claude Code and pick Authenticate:

claude mcp add --transport http runcomfy https://mcp.runcomfy.com/mcp

--transport http is the Streamable HTTP transport. streamable-http is not a value Claude Code accepts, and single-dash -transport / -header are not either — both forms fail before the server is ever contacted.

Check it with claude mcp list, which should show runcomfy: connected.

Claude.ai

Add https://mcp.runcomfy.com/mcp in Settings → Connectors → Add custom connector, then select Connect. Claude discovers RunComfy's OAuth 2.1 endpoints, opens a RunComfy consent page, and asks for one of the API tokens shown in your RunComfy Profile. The token is validated by RunComfy and encrypted inside the MCP authorization grant; it is never returned to Claude.

Cursor

.cursor/mcp.json:

{

"mcpServers": { "runcomfy": { "url": "https://mcp.runcomfy.com/mcp", "headers": { "Authorization": "Bearer YOUR_RUNCOMFY_TOKEN" } } } }

VS Code (Copilot)

.vscode/mcp.json:

{

"servers": { "runcomfy": { "type": "http", "url": "https://mcp.runcomfy.com/mcp", "headers": { "Authorization": "Bearer YOUR_RUNCOMFY_TOKEN" } } } }

Windsurf

Settings → MCP:

{

"mcpServers": { "runcomfy": { "serverUrl": "https://mcp.runcomfy.com/mcp", "headers": { "Authorization": "Bearer YOUR_RUNCOMFY_TOKEN" } } } }

Any other client

• URL: https://mcp.runcomfy.com/mcp
• Transport: Streamable HTTP
• Auth: Authorization: Bearer on every request, or OAuth 2.1 with a loopback redirect URI or an exact supported client callback

Troubleshooting

Revoke access by regenerating the token in your RunComfy Profile. That invalidates the token header and any OAuth grant built on it, because every MCP request revalidates the token upstream.

---

Architecture

MCP Client ──RunComfy API token──┐

│ Cloudflare Worker (/mcp) MCP Client ──MCP OAuth token─────┤ validates the credential, resolves │ it to one user's RunComfy token ▼ Cloudflare Container (Python FastMCP app) │ request-scoped RunComfy credential ┌───────────────┼───────────────┐ ▼ ▼ ▼ api.runcomfy.net model-api. trainer-api. (Serverless) runcomfy.net runcomfy.net (Model) (Trainer)

One RunComfy token authenticates all three products, so the same credential resolution covers every tool.

Both credential kinds converge on the same request-scoped identity header before the container is reached. They are told apart by shape: OAuth access tokens are always userId:grantId:secret, and a RunComfy API token never contains a colon.

• Cloudflare Worker (src/index.ts) — OAuth 2.1 authorization server and protected-resource boundary. Missing, invalid, expired, or wrong-audience credentials are rejected before MCP initialization or tool discovery.
• Direct API token (src/index.ts) — a RunComfy Profile token presented as Authorization: Bearer is revalidated against api.runcomfy.net on every request, rate-limited per source IP, and never forwarded as-is.
• OAuth consent (src/oauth-bridge.ts) — validates an existing RunComfy Profile token, stores it only in encrypted OAuth grant data, and issues a separate audience-bound MCP access token. Dynamic client registration accepts loopback callbacks (Claude Code and other local clients), an exact allowlist of hosted client callbacks, and Cursor's exact legacy app callback. Cursor registers cursor://anysphere.cursor-mcp/oauth/callback, https://www.cursor.com/agents/mcp/oauth/callback, and http://localhost:8787/callback together; all three must be accepted even when the active redirect uses localhost. Arbitrary custom protocols and callback variants remain rejected, and S256 PKCE is required.
• Python container (server.py) — FastMCP app with 31 tools across the Serverless, Model, and Trainer APIs. It has no shared/operator credential and fails closed unless the authenticated edge supplies the current user's request-scoped RunComfy token.
• Cloudflare Container auto-starts on first request, sleeps after 10 minutes idle.

---

Project layout

.github/workflows/deploy.yml  CI: typecheck, test, deploy to Cloudflare

src/index.ts Cloudflare Worker entrypoint src/oauth-bridge.ts OAuth consent and RunComfy token validation server.py MCP tool definitions (31 tools) runcomfy_client.py RunComfy API clients (serverless, model, trainer) container_app.py ASGI middleware (request IDs, token forwarding) container_entrypoint.py Uvicorn startup container_runtime.py Env validation, structured logging wrangler.jsonc Cloudflare Worker + Container config Dockerfile Container image .env.example Local dev config

---

Local development

# Python 3.11+

python3.11 -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp .env.example .env python -m container_entrypoint

Local endpoints:

• http://127.0.0.1:8000/healthz
• http://127.0.0.1:8000/mcp

The local Python endpoint intentionally has no shared fallback credential. Protected tool calls must go through the authenticated Worker boundary.

---

Deploy

Pushing to main deploys automatically via .github/workflows/deploy.yml: typecheck, Worker tests, and container tests must pass, then wrangler deploy --containers-rollout immediate ships the Worker and the Python container together. Pull requests run the same checks without deploying. The workflow can also be run by hand from the Actions tab.

One repository secret is required:

To deploy by hand (requires C