Skip to main content
Glama

list_models

Read-onlyIdempotent

Identify the correct model_id for your inference by searching and filtering available ComfyUI models. See pricing, inputs, and descriptions to choose the right model.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo
limitNo
offsetNo
searchNo
categoryNo
include_schemaNo

Schema Changelog

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

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: the exact entry shape (model_id, display_name, description, base_price_usd per price_unit, model_url, inputs/required_inputs), pagination semantics ('total is the unpaged count'), and the response-size consequence of include_schema ('Much larger response'). No contradiction with annotations.

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 long (~200 words) but every section earns its place: one-sentence purpose, API mapping, return-entry shape, then tight per-parameter docs. It is front-loaded with the purpose and use case before details. The only deduction is that the Args block could have lived in the schema, but given 0% schema coverage, embedding it in the description was the correct choice.

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?

With no output schema, the return-shape paragraph compensates well by listing what each entry carries. Filtering, search case-insensitivity, category source, kind values, pagination, and the include_schema tradeoff are all covered. Minor gaps remain — no statement about result ordering or how filters combine — but these are small against the overall completeness for a 6-parameter tool.

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 description coverage is 0%, so the description carries the full burden — and it fully compensates. All 6 parameters are documented with meaningful semantics: search gives match targets and concrete examples, category gives capability examples and a pointer to list_model_categories, kind enumerates allowed values and notes orthogonality to category, and limit/offset specify bounds and paging behavior. This exceeds what a bare schema would provide.

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?

Opens with a specific verb+resource+scope: 'Browse the hosted models that run_model can run.' This immediately distinguishes it from siblings like get_model (single fetch), run_model (execution), and list_model_categories (taxonomy). The 'Backs GET /v1/models' mapping and the 'Start here when you know what you want to generate but not which model_id provides it' framing make the intent unmistakable.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance ('Start here when you know what you want to generate but not which model_id provides it') and names alternatives with conditions: 'Use list_model_categories for the full set' of categories, and 'prefer get_model for a single model, and use this only when comparing many' for include_schema. An agent is routed correctly without opening schemas.

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