Skip to main content
Glama

find_node_types

Search ComfyUI node types by name, input/output types, category, or pack to find matching nodes for your workflow.

Instructions

Find a node type to add to a workflow, by name or by what it connects to.

Filters are ANDed and all are optional; with none of them this lists what is installed. Each result carries the node's slots, so it is usually enough on its own - reach for describe_node when you need a widget's allowed values.

The type filters answer the question a graph editor actually asks. "What turns a LATENT into an IMAGE" is input_type='LATENT', output_type='IMAGE'; searching for the word 'latent' would never find VAEDecode, whose name and category contain neither word.

Args: search: case-insensitive substring, matched against the node's name, title, category, description, and the search aliases ComfyUI ships - which is why 'latent to image' finds VAEDecode. input_type: only nodes accepting this slot type, e.g. 'IMAGE', 'MODEL'. output_type: only nodes producing it. Wildcard ('*') slots match anything, as they do when the link is drawn, but rank below nodes that name the type. category: substring of the node's category path, e.g. 'upscal', 'loaders'. pack: substring of the pack it came from, e.g. 'kjnodes', 'comfy_extras'. include_deprecated: include nodes ComfyUI marks as superseded. Off by default because something replaced them. Experimental nodes are always included - that flag means new, not unreliable. include_api: include paid cloud API nodes, which need an account. refresh: re-fetch /object_info first. Needed after installing nodes. limit: maximum results. What matched beyond it is still counted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packNo
limitNo
searchNo
refreshNo
categoryNo
input_typeNo
include_apiNo
output_typeNo
include_deprecatedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries the full burden and excels. It discloses AND semantics, wildcard behavior ('Wildcard ('*') slots match anything'), default exclusions (include_deprecated off), inclusion of experimental nodes, the refresh requirement after installing nodes, and limit behavior ('What matched beyond it is still counted'). It also notes that each result carries the node's slots, so additional calls may be unnecessary. This is deep, actionable transparency.

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 front-loaded with the core purpose, followed by a short paragraph on filter semantics, then a structured Args list. Every sentence earns its place: examples, exclusions, and parameter details are dense but not redundant. Despite covering 9 params, it remains appropriately sized and well organized.

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 the tool's complexity (9 optional parameters, no annotations) and the presence of an output schema, the description is complete. It explains all parameters, usage context, alternatives, and behavioral nuances. There are no obvious gaps; an agent will know exactly when and how to invoke this 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 must fully compensate, and it does. Every one of the 9 parameters is explained with examples ('search: case-insensitive substring... why 'latent to image' finds VAEDecode'), type semantics ('input_type' vs 'output_type'), wildcard ranking, and default behaviors. This adds substantial meaning beyond the bare parameter names and types in the schema.

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: 'Find a node type to add to a workflow, by name or by what it connects to.' It clearly distinguishes this from sibling tools like describe_node by stating when to use describe_node instead (for a widget's allowed values). The purpose is unmistakable and differentiated.

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?

Explicit guidance is provided: 'Filters are ANDed and all are optional; with none of them this lists what is installed.' It also names the alternative: 'reach for describe_node when you need a widget's allowed values.' The 'type filters answer the question a graph editor actually asks' gives concrete use cases, making when/how to use this tool clear.

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

Install Server

Other Tools

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/pytraveler/local-comfyui-mcp'

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