Skip to main content
Glama
ousiqwq

comfy-mcp-local

by ousiqwq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_models

List and search model files in your local ComfyUI installation. Use a filename query or specify a folder to verify which models exist before downloading.

Instructions

Search / list model files available to the LOCAL ComfyUI install.

Three modes: query -> comfy models search --text <query> (filename match, all folders on v1.14.0+, checkpoints only below the floor); else folder -> comfy models list-folder <folder>; else -> comfy models list-folders (folder names).

query tokens match word-order-independently and ignore - _ . separators, so "sdxl base" finds sd_xl_base_1.0.safetensors. That needs a comfy-cli NEWER than v1.15.0 (Comfy-Org/comfy-cli#684, merged after v1.15.0 was cut); on v1.15.0 and older the whole query is one substring, so search a single word there.

RESPONSE SHAPE DIFFERS BY MODE: query returns {rows: [...]}, folder returns {files: [...]}. Filenames only — no base-model/ hash/description enrichment.

Freshness: LIVE — re-read from disk every call; filenames only, no registry metadata, so an absent name never means "no such model". It is either (a) present but outside what this call searched (each mode looks narrower than "the install" — re-check with folder="loras"/"vae" before concluding anything, since acting wrong triggers a redundant multi-GB download), or (b) genuinely not downloaded — use download_model, which refuses on a remote target rather than write to a disk it can't read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
folderNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A5/5.0
Behavior5/5

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

With no annotations to carry safety or behavior, the description fully discloses live disk reads, filename-only results with no registry metadata, mode-dependent response shapes, query token normalization, and version-dependent substring matching. It also explains the operational consequence of false negatives, which is exactly the behavioral context an agent needs.

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

Conciseness5/5

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

The text is dense but every sentence earns its place given the mode-dependent complexitycars. It is front-loaded with the core purpose, uses clear section labels, and avoids fluff while covering version, response shape, and freshness caveats.

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

Completeness5/5

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

Given no output schema and no annotations, the description fully covers return shapes per mode, version constraints, matching semantics, and what absence of results means. Nothing an agent needs to invoke this tool correctly or interpret its output is missing.

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%, but the description compensates thoroughly by explaining how query tokens are matched, how folder restricts the search, and how the two optional parameters interact to select modes. Concrete examples and caveats such as 'sdxl base' and folder='loras'/'vae' make both parameters semantically clear.

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 explicitly states the tool searches/lists model files on the local ComfyUI installro, defines three distinct modes with exact CLI equivalents, and clearly differentiates it from sibling tools like search_templates and download_model. The verb and resource are specific and immediately actionable.

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?

It provides explicit mode-selection rules (query first, then folder, then list-folders), version-specific behavior guidance, and names download_model as the alternative when a model is genuinely absent. It also advises re-checking with folder='loras'/'vae' before concluding non-existence, which is a precise usage directive.

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

Deploy Server

Other Tools