Skip to main content
Glama

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

Category

Tools

Deployment management

list_deployments, get_deployment, create_deployment, update_deployment, delete_deployment

Inference

submit_request, get_request_status, get_request_result, cancel_request

Advanced

call_instance_proxy

Model API — hosted catalog models, on demand

Docs: docs.runcomfy.com/model-apis

Category

Tools

Catalog

list_models, get_model, list_model_categories

Inference

run_model, get_model_request_status, get_model_request_result, cancel_model_request

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

Category

Tools

Datasets

create_dataset, list_datasets, get_dataset_status, delete_dataset

Dataset uploads

upload_dataset_file_from_url, upload_dataset_text_file, get_dataset_upload_urls

Training jobs

submit_training_job, get_training_job_status, get_training_job_result, cancel_training_job, resume_training_job, edit_training_job

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

Category

Tools

Balance

get_balance

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.


Related MCP server: ComfyUI MCP

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 <token> on every request, or OAuth 2.1 with a loopback redirect URI or an exact supported client callback

Troubleshooting

Symptom

Cause

401 with RunComfy rejected this API token

The token is wrong, expired, or truncated on copy. Generate a new one in Profile — the response body names the fix.

401 with no error_description

No Authorization header reached the server. Check the header is quoted as one argument: --header "Authorization: Bearer ...".

invalid_client_metadata during OAuth

The client registered a callback outside the loopback and exact client allowlist. Use a supported callback or the token header.

invalid_target during OAuth

The configured URL must be exactly https://mcp.runcomfy.com/mcp — no trailing slash. RFC 8707 binds the token to that exact resource.

503 with Retry-After

RunComfy's API could not be reached to verify the token. Retry.

429

More than 600 token-authenticated requests a minute from one IP.

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:

Secret

Purpose

CLOUDFLARE_API_TOKEN

A token with Edit Cloudflare Workers permission on the account in wrangler.jsonc

CLOUDFLARE_ACCOUNT_ID

Optional. account_id is already committed in wrangler.jsonc; set this only to deploy under a different account.

To deploy by hand (requires Cloudflare Workers Paid plan with Containers enabled):

npm install
npm run check
npm test
npx wrangler deploy --containers-rollout immediate

The MCP endpoint goes live at https://mcp.runcomfy.com/mcp (custom domain configured in wrangler.jsonc).


Environment variables and bindings

There is deliberately no shared RunComfy API-key secret. OAuth state is kept in the OAUTH_KV binding and every upstream request is tied to the user who authorized the OAuth grant.

Worker vars (in wrangler.jsonc)

Name

Default

Description

CONTAINER_INSTANCE_NAME

runcomfy-unified

Durable Object instance name

CONTAINER_STARTUP_TIMEOUT_MS

15000

Max wait for container start

CONTAINER_PORT_READY_TIMEOUT_MS

30000

Max wait for port ready

MCP_MAX_BODY_BYTES

1048576

Max request body size

OPENAI_APPS_CHALLENGE

Current submission token

Public OpenAI domain-verification token, served verbatim at GET /.well-known/openai-apps-challenge; unset or empty returns 404. Verify ownership of any existing token before replacing it.

MCP_DIRECT_TOKEN_RATE_LIMITER

600 / 60s

Per-IP cap on API-token-authenticated /mcp requests

RUNCOMFY_SERVERLESS_BASE_URL

https://api.runcomfy.net

Serverless API base URL

RUNCOMFY_MODEL_API_BASE_URL

https://model-api.runcomfy.net

Model API base URL

RUNCOMFY_TRAINER_API_BASE_URL

https://trainer-api.runcomfy.net

Trainer API base URL

Local Python dev (.env file)

Name

Required

Description

RUNCOMFY_SERVERLESS_BASE_URL

No

Override Serverless base URL (default: https://api.runcomfy.net)

RUNCOMFY_MODEL_API_BASE_URL

No

Override Model API base URL (default: https://model-api.runcomfy.net)

RUNCOMFY_TRAINER_API_BASE_URL

No

Override Trainer API base URL (default: https://trainer-api.runcomfy.net)

RUNCOMFY_MCP_MOUNT_PREFIX

No

Path prefix for MCP mount (default: empty)

Available Tools

31 tools
call_instance_proxyA
Destructive
Inspect

Call a ComfyUI backend endpoint on a live instance.

Backs ``POST /prod/v2/deployments/{deployment_id}/instances/{instance_id}/proxy/{path}``.

Get the instance_id from ``get_request_status`` once the status is
``in_progress``. Common target: ``api/free`` with
``{"unload_models": true}`` to free GPU memory.

Inputs: instance_id (required), deployment_id (required), comfy_backend_path (required), request_body.

cancel_model_requestA
DestructiveIdempotent
Inspect

Cancel a queued Model API request.

Backs ``POST /v1/requests/{request_id}/cancel``. Returns
``cancelled`` if accepted, ``not_cancellable`` if the request is
already in progress or finished.

Inputs: request_id (required).

cancel_requestA
DestructiveIdempotent
Inspect

Cancel a queued or running request.

Backs ``POST /prod/v1/deployments/{deployment_id}/requests/{request_id}/cancel``.
Returns ``cancelled`` if accepted, ``not_cancellable`` if already done.

Inputs: request_id (required), deployment_id (required).

cancel_training_jobA
DestructiveIdempotent
Inspect

Cancel a queued or running training job.

Backs ``POST /prod/v1/trainers/ai-toolkit/jobs/{job_id}/cancel``.
Progress stops, but ``get_training_job_result`` still returns any
checkpoints produced so far.

Inputs: job_id (required).

create_datasetAInspect

Create an empty training dataset.

Backs ``POST /prod/v1/trainers/datasets``. The new dataset starts in
``DRAFT``; upload files into it, then poll ``get_dataset_status``
until it reaches ``READY`` before submitting a training job.

Args:
    name: Human-readable name, unique within the account. This is
        the ``dataset_name`` an AI Toolkit config references as
        ``/app/ai-toolkit/datasets/{dataset_name}``. Omit to let
        RunComfy generate one.

Inputs: name.

create_deploymentA
Destructive
Inspect

Create a Serverless API (ComfyUI) deployment.

Backs ``POST /prod/v2/deployments``. For LoRA deployments, create
via the runcomfy.com UI instead.

Args:
    name: Human-readable name.
    workflow_id: UUID of the ComfyUI workflow.
    workflow_version: Version label, e.g. "v1".
    hardware: One of TURING_16, AMPERE_24, AMPERE_48, ADA_48_PLUS,
        AMPERE_80, ADA_80_PLUS, HOPPER_141.
    min_instances: 0..30. Warm instance floor (billable if > 0).
    max_instances: 1..60. Concurrency ceiling.
    queue_size: >= 0. Pending requests before scaling up.
    keep_warm_duration_in_seconds: >= 0. Idle timeout.

Inputs: name (required), workflow_id (required), workflow_version (required), hardware, +4 more.

delete_datasetA
DestructiveIdempotent
Inspect

Permanently delete a training dataset.

Backs ``DELETE /prod/v1/trainers/datasets/{dataset_id}``. This
cannot be undone.

Inputs: dataset_id (required).

delete_deploymentA
DestructiveIdempotent
Inspect

Permanently delete a deployment.

Backs ``DELETE /prod/v2/deployments/{deployment_id}``. This cannot
be undone. Consider ``update_deployment(is_enabled=false)`` to pause
instead.

Inputs: deployment_id (required).

edit_training_jobA
Destructive
Inspect

Replace the config of a non-running training job.

Backs ``POST /prod/v1/trainers/ai-toolkit/jobs/{job_id}/edit``. Only
works while the job is ``STOPPED``, ``CANCELED``, or ``FAILED``, and
``config.name`` in the new YAML must still match the original job's
name. GPU type and count are chosen at resume time, so call
``resume_training_job`` afterwards to re-queue with the new config.

Inputs: job_id (required), config_file (required).

get_balanceA
Read-onlyIdempotent
Inspect

Get the account's remaining RunComfy balance.

Backs ``GET /prod/v2/balance``. One wallet funds every product, so
this is the figure Serverless deployments, ``run_model`` requests,
and training jobs all draw down — and the one that gets checked
before work is allowed to start.

Returns ``balance_usd`` for reading and ``balance_microdollars``
(millionths of a dollar) for exact arithmetic.

Inputs: no named parameters.

get_dataset_statusA
Idempotent
Inspect

Get a dataset's status and its successfully uploaded files.

Backs ``GET /prod/v1/trainers/datasets/{dataset_id}/status``.
Lifecycle: ``DRAFT`` → ``UPLOADING`` → ``READY`` (or ``FAILED``,
which sets ``error``). Only ``READY`` datasets can be mounted by a
training job. Files still uploading or failed do not appear in
``files``.

Inputs: dataset_id (required).

get_dataset_upload_urlsAInspect

Get signed upload URLs for dataset files the server cannot fetch.

Backs ``POST /prod/v1/trainers/datasets/{dataset_id}/get-upload-endpoint``.
Use this for local files and for anything over 150 MB: the caller
PUTs each file's bytes to the returned ``upload_url`` using the
returned ``method`` and ``headers``.

Args:
    dataset_id: Target dataset.
    filename_to_byte_size: Map of filename → exact size in bytes,
        e.g. ``{"img_0001.jpg": 2000000, "img_0001.txt": 12000}``.
        The signature is derived from the size, so a wrong value is
        rejected by storage at PUT time.

Signed URLs are short-lived; call this again for a fresh one if it
expires. After every PUT succeeds, poll ``get_dataset_status`` until
the dataset is ``READY``.

Inputs: dataset_id (required), filename_to_byte_size (required).

get_deploymentA
Read-onlyIdempotent
Inspect

Get one deployment by ID.

Backs ``GET /prod/v2/deployments/{deployment_id}``.

Set include_payload=true to inspect the deployed workflow graph
(workflow_api_json) and default overrides — use the node IDs and
input names to build the ``overrides`` for ``submit_request``.

Inputs: deployment_id (required), include_readme, include_payload.

get_modelA
Read-onlyIdempotent
Inspect

Get one hosted model's input schema.

Backs ``GET /v1/models/{model_id}``. The ``input_schema`` is the
JSON Schema for ``run_model``'s ``inputs`` — property types,
defaults, enums, and min/max ranges — so read it before building a
request rather than guessing parameter names. Properties whose
``format`` is ``image_uri``/``video_uri``/``audio_uri`` take a
public HTTPS URL.

Also returns ``description``, ``categories``, ``base_price_usd``
per ``price_unit``, and ``model_url``.

Args:
    model_id: The model's identifier, slashes included, e.g.
        ``blackforestlabs/flux-1-kontext/pro/edit``. Find one with
        ``list_models``.

Inputs: model_id (required).

get_model_request_resultA
Read-onlyIdempotent
Inspect

Fetch a completed Model API request's outputs.

Backs ``GET /v1/requests/{request_id}/result``. The ``output`` shape
is defined by the model's Output schema; any hosted asset URLs found
in it are also flattened into ``output_urls``.

This is for ``run_model`` requests. Serverless deployment requests
use ``get_request_result`` instead.

Inputs: request_id (required).

get_model_request_statusA
Read-onlyIdempotent
Inspect

Poll a Model API request's current status.

Backs ``GET /v1/requests/{request_id}/status``.
Lifecycle: ``in_queue`` → ``in_progress`` → ``completed`` /
``cancelled``. While ``in_queue`` the payload also carries
``queue_position``.

This is for ``run_model`` requests. Serverless deployment requests
use ``get_request_status`` instead.

Inputs: request_id (required).

get_request_resultA
Read-onlyIdempotent
Inspect

Fetch a completed request's outputs.

Backs ``GET /prod/v1/deployments/{deployment_id}/requests/{request_id}/result``.
Output URLs are hosted for 7 days.

This is for ``submit_request`` requests on a deployment. Model API
requests from ``run_model`` use ``get_model_request_result``.

Inputs: request_id (required), deployment_id (required).

get_request_statusA
Read-onlyIdempotent
Inspect

Poll a request's current status.

Backs ``GET /prod/v1/deployments/{deployment_id}/requests/{request_id}/status``.
Lifecycle: ``in_queue`` → ``in_progress`` → ``completed`` / ``cancelled``.

This is for ``submit_request`` requests on a deployment. Model API
requests from ``run_model`` use ``get_model_request_status``.

Inputs: request_id (required), deployment_id (required).

get_training_job_resultA
Read-onlyIdempotent
Inspect

Fetch a training job's artifacts as hosted URLs.

Backs ``GET /prod/v1/trainers/ai-toolkit/jobs/{job_id}/result``.
Returns checkpoints (``.safetensors``), the resolved config, and
sample outputs. Safe to call while the job is still ``RUNNING`` —
the artifact list grows over time — and after a ``FAILED`` or
``CANCELED`` job to recover whatever was produced.

Feed a checkpoint URL to ``run_model`` as
``{"lora": {"path": "<url>"}}`` to run inference on it.

Inputs: job_id (required).

get_training_job_statusA
Read-onlyIdempotent
Inspect

Poll a training job's status and step progress.

Backs ``GET /prod/v1/trainers/ai-toolkit/jobs/{job_id}/status``.
Lifecycle: ``IN_QUEUE`` → ``RUNNING`` → ``STOPPED`` (finished or
preempted), ``FAILED`` (``error`` explains why), or ``CANCELED``.

Inputs: job_id (required).

list_datasetsA
Read-onlyIdempotent
Inspect

List training datasets in the caller's account.

Backs ``GET /prod/v1/trainers/datasets``. Use it to find the
``id`` (for upload/status/delete calls) and the ``name`` (for the
``folder_path`` in an AI Toolkit config). The listing carries no
per-file detail — use ``get_dataset_status`` for a dataset's files.

Args:
    include_raw: Return each dataset's unabridged payload instead of
        the compact summary. Larger response.

Inputs: include_raw.

list_deploymentsA
Read-onlyIdempotent
Inspect

List Serverless API deployments in the caller's account.

Backs ``GET /prod/v2/deployments``.

Args:
    ids: Optional list of deployment IDs to filter to.
    include_payload: Include workflow_api_json, overrides, and
        object_info_url for each deployment. Larger response.
    include_readme: Include the deployment's README markdown.

Inputs: ids, include_readme, include_payload.

list_model_categoriesA
Read-onlyIdempotent
Inspect

List the capability categories models are grouped into.

Backs ``GET /v1/models/categories``. Returns values such as
``text-to-image`` and ``image-to-video`` — pass one to
``list_models(category=...)``.

Inputs: no named parameters.

list_modelsA
Read-onlyIdempotent
Inspect

Browse the hosted models that run_model can run.

Backs ``GET /v1/models`` on the Model API. Start here when you know
what you want to generate but not which ``model_id`` provides it.

Each entry carries the ``model_id`` for ``run_model``, a
``display_name`` and ``description``, what it costs
(``base_price_usd`` per ``price_unit``), a ``model_url`` to the
model's page, and its ``inputs`` / ``required_inputs``.

Args:
    search: Case-insensitive match on id, display name, or
        description — e.g. "kontext", "upscale", "lip sync".
    category: Capability filter, e.g. ``text-to-image``,
        ``image-to-video``. Use ``list_model_categories`` for the
        full set.
    kind: How the model runs — ``model``, ``workflow``, or
        ``inference``. Orthogonal to ``category``; filter on
        ``category`` unless you specifically care how it executes.
    include_schema: Return each model's full ``input_schema``
        inline. Much larger response — prefer ``get_model`` for a
        single model, and use this only when comparing many.
    limit: Page size, 1..500.
    offset: Rows to skip. ``total`` is the unpaged count.

Inputs: kind, limit, offset, search, +2 more.

resume_training_jobA
Destructive
Inspect

Resume a stopped training job from its latest checkpoint.

Backs ``POST /prod/v1/trainers/ai-toolkit/jobs/{job_id}/resume``.
Reuses the same ``job_id`` rather than creating a new job, and
restarts from the highest-step checkpoint (from step 0 if none
exists). Useful after a preemption; for a ``FAILED`` job, read
``error`` from the status first and fix the cause — often via
``edit_training_job`` — before resuming.

Inputs: job_id (required).

run_modelA
Destructive
Inspect

Run a hosted RunComfy model on demand — no deployment needed.

Backs ``POST /v1/models/{model_id}`` on the Model API. Returns a
``request_id`` immediately; poll with ``get_model_request_status``
and fetch outputs with ``get_model_request_result``.

Args:
    model_id: The model's identifier exactly as shown on its page at
        runcomfy.com/models, e.g.
        ``blackforestlabs/flux-1-kontext/pro/edit``. Slashes are part
        of the ID.
    inputs: Request body matching the model's Input schema (model
        page → API → Input schema), e.g.
        ``{"prompt": "a cat", "aspect_ratio": "16:9", "seed": 42}``.
    wait_for_completion: If true, poll until done and return the
        result inline.
    timeout_seconds: Max wait when wait_for_completion=true.

File inputs must be publicly accessible HTTPS URLs that a plain
unauthenticated GET can fetch, e.g.
``{"image_url": "https://example.com/photo.webp"}``.

To run a Trainer LoRA without deploying it, call the LoRA's *base
model* ID here and pass the LoRA in the body, e.g.
``{"lora": {"path": "my_first_lora_3000.safetensors"}}`` — either a
LoRA name from your RunComfy LoRA Assets or a public URL.

Inputs: model_id (required), inputs, timeout_seconds, wait_for_completion.

submit_requestA
Destructive
Inspect

Submit an async inference request to a deployment.

Backs ``POST /prod/v1/deployments/{deployment_id}/inference``.

Args:
    deployment_id: Target deployment.
    overrides: Partial graph keyed by node_id, e.g.
        ``{"6": {"inputs": {"text": "a cat"}}}``.
        Use ``get_deployment(include_payload=true)`` to discover
        node IDs and input names.
    workflow_api_json: Advanced — run a different workflow without
        updating the deployment. Omit ``overrides`` in this mode.
    extra_data: E.g. ``{"api_key_comfy_org": "comfyui-..."}`` for
        ComfyUI Core API nodes.
    webhook_url: Push-based updates instead of polling.
    webhook_intermediate_status: Fire webhooks on every status
        change, not just terminal.
    wait_for_completion: If true, poll until done and return the
        result inline.
    timeout_seconds: Max wait when wait_for_completion=true.

File inputs: pass a public HTTPS URL or Base64 data URI directly
in the overrides value, e.g.
``{"189": {"inputs": {"image": "https://example.com/photo.jpg"}}}``
or ``{"189": {"inputs": {"image": "data:image/jpeg;base64,/9j..."}}}``.

Inputs: deployment_id (required), overrides, extra_data, webhook_url, +4 more.

submit_training_jobA
Destructive
Inspect

Submit an AI Toolkit training job (typically LoRA training).

Backs ``POST /prod/v1/trainers/ai-toolkit/jobs``. The job mounts a
``READY`` dataset and runs the config you supply. Training runs for
hours — this returns as soon as the job is queued; track it with
``get_training_job_status`` and pull artifacts with
``get_training_job_result``.

Args:
    config_file: The complete AI Toolkit YAML config as a string.
        Two paths in it are fixed by the platform:
        ``training_folder`` must be ``/app/ai-toolkit/output``, and
        the dataset's ``folder_path`` must be
        ``/app/ai-toolkit/datasets/{dataset_name}`` where
        ``dataset_name`` is the dataset's ``name`` (not its id).
    gpu_type: ``ADA_80_PLUS`` (H100) or ``HOPPER_141`` (H200).
    gpu_count: 1 for single-GPU (default), or 8 for multi-GPU.
        Multi-GPU is only supported on ``ADA_80_PLUS``.
    gpu_id: Optional specific GPU selector, e.g. ``"#1"``.

Inputs: config_file (required), gpu_id, gpu_type, gpu_count.

update_deploymentA
Destructive
Inspect

Partially update a deployment.

Backs ``PATCH /prod/v2/deployments/{deployment_id}``. Only pass the
fields you want to change. Set is_enabled=false to pause;
true to re-enable.

Inputs: deployment_id (required), name, hardware, is_enabled, +5 more.

upload_dataset_file_from_urlA
Destructive
Inspect

Add one file to a dataset by fetching it from a public URL.

Downloads ``source_url`` and forwards the bytes to
``POST /prod/v1/trainers/datasets/{dataset_id}/upload``.

Args:
    dataset_id: Target dataset.
    source_url: Publicly reachable HTTPS URL for an image, video, or
        caption ``.txt`` file. Must be under 150 MB.
    filename: Name to store it under. Defaults to the URL's
        basename. For LoRA training each image/video needs a caption
        ``.txt`` with the *same base name* — ``img_0001.jpg`` pairs
        with ``img_0001.txt``.

Re-uploading the same filename overwrites the previous copy. For
files the caller holds locally, or anything over 150 MB, use
``get_dataset_upload_urls`` and PUT the bytes directly instead.

Inputs: dataset_id (required), source_url (required), filename.

upload_dataset_text_fileA
Destructive
Inspect

Add a text file — normally a caption — to a dataset.

Backs ``POST /prod/v1/trainers/datasets/{dataset_id}/upload`` with
inline text, so captions can be written without hosting a file.

Args:
    dataset_id: Target dataset.
    filename: Must share the base name of the media it captions:
        ``img_0001.jpg`` → ``img_0001.txt``.
    text: Caption body.

Inputs: text (required), filename (required), dataset_id (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4/5.0

    Scored across 31 tools

    Disambiguation4/5

    Tools are grouped by resource with clear action prefixes, so deployments, datasets, models, and training jobs are generally easy to tell apart. The main ambiguity risk is the parallel request-status/result/cancel tools for deployment requests versus model API requests, which require careful reading to avoid misselection.

    Naming Consistency5/5

    All tool names follow a consistent snake_case verb_noun pattern, e.g., create_deployment, list_datasets, submit_training_job, cancel_model_request. Even longer names like upload_dataset_file_from_url and get_dataset_upload_urls stay predictable and readable.

    Tool Count2/5

    At 31 tools, this is a heavy surface and exceeds the 25+ threshold for too many tools. The tools are well organized into deployment, dataset, model, and training clusters, but the MCP would be easier to navigate if split into separate per-domain servers.

    Completeness4/5

    Core platform workflows are well covered: deployment CRUD plus inference lifecycle, model discovery and execution, dataset creation and upload, and training job submission/status/result/cancel/resume/edit. The notable gaps are the lack of a list_training_jobs tool and no way to list past requests, though agents can work around these by capturing IDs from submission calls.

    Maintenance

    ActivitySlowing
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers