Skip to main content
Glama

run_model

Destructive

Run a hosted RunComfy model on demand without deployment. Submit model ID and inputs, optionally wait for completion to get results inline.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsNo
model_idYes
timeout_secondsNo
wait_for_completionNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that it returns a request_id immediately, that wait_for_completion poll and returns the result inline, and that file inputs must be publicly accessible HTTPS URLs. It also explains the LoRA body format. While the destructiveHint annotation implies side effects, the description doesn't mention billing/credit implications, so it's not fully transparent but is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, endpoint mapping, explicit Args section, and useful supplementary notes. It is somewhat long, but each sentence adds operational value such as file URL requirements and LoRA usage, so nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter async execution tool with no output schema, the description covers the main workflow, parameter semantics, file constraints, and the LoRA special case. It doesn't mention error conditions or credit implications, but the core information an agent needs to invoke and poll correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates thoroughly: model_id includes exact format and examples with the note about slashes, inputs explains the Input schema reference and gives a concrete example, and wait_for_completion/timeout_seconds are behaviorally defined. This goes far beyond the bare schema titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run a hosted RunComfy model on demand — no deployment needed.' It also names the backing endpoint (POST /v1/models/{model_id}) and the immediate return value, making the tool's function unmistakable and distinguishing it from deployment/management siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use context: run a hosted model without deploying. It also prescribes the follow-up workflow by pointing to get_model_request_status and get_model_request_result. It does not explicitly say 'use submit_request for deployed endpoints,' but the 'no deployment needed' contrast and async workflow guidance are sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/runcomfy-com/runcomfy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server