Skip to main content
Glama
ousiqwq

comfy-mcp-local

by ousiqwq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_templates

Search built-in ComfyUI workflow templates by free-text query or tag, type, model, and provider filters, with an option to exclude paid API-hosted rows.

Instructions

Search the built-in ComfyUI workflow-template gallery.

Wraps comfy templates ls (~558 rows, narrows/pages it). Returns {"total", "shown", "offset", "rows"} — rows projected to name/title/description/output_type/tags/category_title plus a derived api boolean. API in tags means paid hosted — it spends the signed-in account's credits, so run_template fails it CLOSED unless confirm_spend=True — while api: false runs on local hardware for free; an identically-titled row without the tag is the free sibling (api_minimax_h3_t2v vs video_minimax_h3_t2v) — tags / category_title / api, not the title, tell them apart. api is the same case-insensitive, drift-tolerant test exclude_api filters on (see _template_is_api), so an exclude_api=True page is all api: false; it is the gallery's own tag, not a graph inspection, so it carries the same caveat that filter always has.

Args: query: free-text match over name/title/description/tags/models. Two passes. A PHRASE pass first — the words must appear consecutively — so image to image stays img2img rather than matching every text to image row. Only if that finds nothing does an all-words pass run, and the reply then carries match: "all-words" so a widened result is never mistaken for an exact one. In the all-words pass: EVERY word must prefix a word in the row, so MiniMax Text to Video finds MiniMax H3: Text to Video, and each extra word only narrows. Word-anchored, so flux finds flux2 but ext does not match text. When nothing matches, the reply carries unmatched_query_words naming the dead words. tag/type/model/provider: forwarded filters (tag/type exact, model/provider substring). exclude_api: drop API-tagged rows. limit/offset: page results (limit capped at 200).

Step 1: pick a name, inspect with get_template, then fetch_template. Step 4 — validating before run_workflow — is MANDATORY via local_check.

Freshness: CACHED, 24h TTL as of v1.14.0; refresh via comfy templates refresh. NOT read from the local install.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNo
typeNo
limitNo
modelNo
queryNo
offsetNo
providerNo
exclude_apiNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers extensively: it discloses the return shape, paid API-tag credit implications, the run_template CLOSED failure unless confirm_spend, two-pass query matching, word anchoring, unmatched_query_words, 24-hour cache freshness, and that it is NOT read from the local install. There is no contradiction with annotations because none exist.

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 description is long but densely organized with Args and workflow sections; the most important facts are front-loaded, and every sentence adds meaningful behavioral or parameter detail. Given 8 parameters and zero schema descriptions, the length is justified.

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?

There is no output schema, so the explicit return shape and row projection are necessary and provided. Freshness, parameter semantics, API-caveat guidance, and downstream routing to get_template/fetch_template make the description complete for correct invocation.

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 documents every parameter in detail: query's phrase/all-words behavior, tag/type/model/provider forwarded filters, exclude_api semantics, and limit/offset pagination with a 200 cap. This far exceeds what the bare schema provides.

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: 'Search the built-in ComfyUI workflow-template gallery.' It further distinguishes itself by naming the wrapped command (`comfy templates ls`), the projected row fields, and the derived `api` boolean, clearly separating it from siblings like get_template, fetch_template, and run_template.

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 places the tool in a clear workflow: 'Step 1: pick a name, inspect with get_template, then fetch_template,' and explains downstream run_template behavior for paid API templates. It does not explicitly enumerate when to prefer this over search_models or when not to use it, but the gallery-scoped workflow context is strong.

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