Panel Operations

Panel agent operations

These are the procedures the panel system prompt points at rather than carries. Each tool named here also has its own full MCP description — that description is the authority on parameters and edge cases. This file is the procedure: the order of calls, and the traps that only show up when you string them together.

Jump to the section you need:

• Subgraphs
• Merging and composing workflows
• Reusing subgraphs (blueprint library)
• Targeting a specific workflow
• Opening a staged or downloaded workflow
• Untangling a Get/Set-bus or toggle-heavy graph
• Authoring rgthree Fast Groups toggles
• LoRA Manager autocomplete nodes
• Recommending CivitAI models
• Downloading model weights
• Hardware and runtime stats
• Prompt Director awareness
• Crash recovery for a broken custom node
• Debugging a wrong render with run-to-node
• Multi-stage pipelines on one canvas
• Connecting MCP servers

Subgraphs

Refactor a big graph into toggleable units. Do not reconstruct group membership by hand. panel_query_graph reports every group with its member node_ids on each result's groups — groups are geometric and do not own nodes, so trust that list, not coordinates. To make a region readable and switchable as a UNIT (e.g. a "REPLACEMENT MODE" group), call panel_subgraph_group(group:<title or id>): it wraps that group's nodes into one subgraph node in a single step. Then toggle the whole region with panel_set_node_mode(<subgraph node id>, 'bypass' to turn it OFF / 'active' to turn it ON). To compare variants, queue it twice — panel_run with the subgraph active, then bypass and panel_run again. For an arbitrary node set that is not a group, use panel_create_subgraph with explicit node_ids.

Reading and editing inside one. Call panel_enter_subgraph(node_id) first — then panel_query_graph / panel_graph_outline and the panel_* edit tools operate on the subgraph's inner nodes — and panel_exit_subgraph when you are done.

Exposing interior nodes to the boundary. To wire an interior node to the subgraph's boundary from INSIDE it, do NOT panel_connect to a guessed rail node id — that is the rail and you will get it wrong. Use:

• panel_expose_subgraph_output(from_node_id, from_output) to expose an interior OUTPUT on the output rail, so the parent graph can wire the subgraph node's new output.
• panel_expose_subgraph_input(to_node_id, to_input) to expose an interior INPUT on the input rail.

Read panel_query_graph's rails field (present when viewing a subgraph) to see the current boundary slots — what is already exposed and what still needs it.

Unexposing a boundary slot. panel_unexpose_subgraph_input / _output remove a named rail slot. Host SubgraphNode slots are positional: removing a slot that is not last shifts every later host link. panel_query_graph and panel_graph_outline will still show those later host links as connected (same positional lens); panel_run can then fail with Required input is missing (#2437). The unexpose reply only warns when a later slot remains and the panel did not already reindex (host_links_reindexed); removing the last slot, or a panel ≥0.15.120 that reports reindexed, is not that hazard. Do not trust that connectedness. Repair: panel_exit_subgraph, then disconnect and reconnect each remaining later host link by NAME (not index). Reconnecting by name re-resolves the index. Then re-enter if you still need the interior. Do not invent a reindex via panel_disconnect on a guessed index — a SubgraphNode disconnect can cascade into deleting unrelated nodes.

Dissolving one. panel_unpack_subgraph(node_id) inlines the inner nodes back into the parent graph and rewires external links, removing the wrapper — the inverse of panel_create_subgraph. All of these are undoable with Ctrl+Z.

Merging and composing workflows

To bring nodes from ONE workflow into ANOTHER (combine two graphs, copy a section across tabs, reuse part of a saved workflow), use copy/paste:

1. panel_open_workflow — the source.
2. panel_select_nodes — the section you want, or select all the ids from panel_query_graph {fields:'ids'}.
3. panel_copy_nodes.
4. panel_open_workflow or panel_new_workflow — the destination.
5. panel_paste_nodes — returns the new node ids.
6. Wire and tidy them, applying the workflow-layout skill so the merged result is clean with no overlaps.

The clipboard SURVIVES the workflow switch, so the copied nodes carry across tabs. Use connect_inputs only when you want the pasted nodes to auto-reconnect to matching existing nodes; the default (false) drops a clean disconnected copy you wire yourself.

Reusing subgraphs (blueprint library)

When the user builds a useful subgraph and wants to reuse it — now or in other workflows — SAVE it: panel_create_subgraph to group the nodes (if not already a subgraph), then panel_save_subgraph(node_id, name) publishes it to their library programmatically (no dialog). To drop a saved one into ANY workflow later, list them with panel_list_subgraphs and add with panel_add_subgraph(name).

This is the durable way to reuse a building block across projects — distinct from copy/paste, which is a one-off merge of the current clipboard.

Targeting a specific workflow

By default your panel_* graph edits follow whichever workflow tab the user is currently viewing. The panel can only read or edit the workflow currently IN VIEW, so to work on a specific open workflow, make it the active canvas first with panel_open_workflow, then call panel_set_workflow_target(mode:"pinned", path:<from panel_list_workflows>) to bind your edits to it. panel_get_workflow_target shows the current binding.

Pinning to a background (open but not active) workflow is REJECTED at pin time — it cannot route edits to a tab that is not in view. A pin does NOT switch what the user sees; it binds your edits to that workflow so that if the user later switches away, your next graph call fails loudly instead of silently editing the wrong graph. Set mode:"current" to follow the user's active tab again.

Tabs are managed with panel_list_workflows / panel_open_workflow / panel_rename_workflow / panel_close_workflow. To label, move, resize, recolor, collapse, or pin a node for presentation, use panel_edit_node.

Opening a staged or downloaded workflow

When you have saved or downloaded a workflow .json into the user's ComfyUI workflows folder (e.g. an example you fetched), open it with panel_open_workflow(path:<name-or-path>) — it REFRESHES the frontend's cached workflow list before searching, so a just-staged file is found and opened natively in its own tab.

For a workflow .json that lives OUTSIDE the workflows folder (any absolute path on the ComfyUI machine, or a downloaded example you did not move into workflows/), load it directly onto the live canvas with panel_load_workflow(path:<file>) — the orchestrator reads and parses the JSON server-side and drops it on the canvas in one shot, so even a large (100KB+) workflow never has to shuttle through the chat. Prefer panel_load_workflow(path:<file>) over pasting a big workflow JSON inline as the graph argument.

Untangling a Get/Set-bus or toggle-heavy graph

Expert and community graphs are often thick with VIRTUAL WIRING — GetNode/SetNode buses and Reroutes that hide the real connections — and rgthree "Fast Groups Bypasser/Muter" TOGGLED PIPELINES (one graph holding several pipelines, only one active at a time). Do NOT hand-trace GetNode to SetNode links or guess which branches are live.

• To get the REAL wiring: panel_strip_workflow(path:<file> | pack:<name> | graph:<json>), or with no argument to read the LIVE canvas. It resolves Get/Set buses, Reroutes, subgraph definitions, and bypassed/muted nodes into REAL connections and returns the flat, runnable graph (read server-side, never shuttled through chat).
• If the file is a MULTI-PIPELINE monolith and you want only ONE pipeline, FIRST panel_slice_workflow(path:<file>, groups:[<group-title substrings>]) to carve that pipeline into a standalone activated graph — it seeds from the output nodes in those groups, takes their backward closure through links and Set/Get buses, and un-bypasses the kept nodes — THEN panel_strip_workflow to flatten the buses.

Reach for panel_strip_workflow whenever a graph is too tangled to read directly or you need to UNDERSTAND or REBUILD its actual wiring; reach for panel_slice_workflow when an ULTRA-style monolith bundles several toggled pipelines and you want just one. The same two exist as get_workflow (action:"strip") and get_workflow (action:"slice") for non-panel sessions.

Authoring rgthree Fast Groups toggles

The counterpart to reading them, above. Fast Groups Bypasser/Muter are FRONTEND-ONLY — registered by the pack's JS and absent from /object_info BY DESIGN, so their absence there is NOT evidence they are unavailable. panel_add_node adds them: it exempts a small allowlist of genuinely frontend-only types covering the Fast (Groups) Bypasser/Muter, Label, Reroute and Node Collector — but NOT Bookmark, the Mute/Bypass Relay/Repeater, Fast Actions Button or Random Unmuter, which it refuses fail-closed.

Procedure and traps:

• They are configured with panel_set_property, NOT panel_set_widget — matchTitle, matchColors, sort and toggleRestriction are node PROPERTIES, and panel_set_widget refuses them.
• They take no wiring and enumerate GROUPS by title, so create and NAME the groups FIRST, and ALWAYS set matchTitle or the node lists every group in the workflow.
• Set matchTitle immediately after adding the node, then re-read the node. Fast Groups do NOT implement onPropertyChanged, so the first write stores the filter but may leave leftover Enable rows or widgets:{} (unbuilt, not "no matches"). If the list is wrong, set matchTitle AGAIN — do NOT delete and re-add the node.
• Group membership is GEOMETRIC (any node whose centre lands in the box). When panel_create_group returns extra_node_ids / missing_node_ids and a warning, FIX IT before toggling, or a toggle disables part of the wrong stage.

Load the rgthree skill (list_packs (action:"skill_read", name:"rgthree")) before configuring these.

LoRA Manager autocomplete nodes

panel_add_node cannot add "Lora Loader (LoraManager)", "Lora Stacker (LoraManager)", or other LoRA Manager nodes whose required input is AUTOCOMPLETE_TEXT_LORAS / AUTOCOMPLETE_TEXT_PROMPT — the add waits 5s and refuses even when the pack and its UI are healthy. That is NOT a missing extension: reloading, panel_refresh_nodes, and retrying will keep failing.

Use "LoRA Text Loader (LoraManager)" instead (lora_syntax is a STRING socket you can drive) or the core LoraLoader. Load the lora-manager skill (list_packs (action:"skill_read", name:"lora-manager")) before authoring these.

Recommending CivitAI models

SHOW, don't just tell. When the user asks about — or you are recommending — specific CivitAI resources (a "good relight LoRA?", "which Flux checkpoint?", "find me an anime style"), LEAN TOWARD opening the docked CivitAI browser and highlighting your picks rather than answering with only a text table:

1. panel_open_civitai — docked, with a matched query/tab/filters.
2. panel_civitai_search — refine.
3. panel_civitai_results — read the metadata and URLs.
4. panel_civitai_highlight — the one(s) you recommend, with a BRIEF text summary of why each fits.

This docks beside the chat so both stay visible, and lets the user SEE the actual cards. You read metadata and URLs only, not the images. It is a nudge, not a mandate — a quick factual answer, or a resource the user already named, is fine as text; reach for the browser when they are choosing between options or exploring.

Downloading model weights

Use download_model (action:"download"), or action:"download_civitai" for CivitAI — NOT a raw shell download. It streams the file into the correct ComfyUI models/ subfolder AND surfaces live progress in the panel's download tray so the user can watch it. Pass target_subfolder to land the file exactly where it belongs (e.g. loras, checkpoints, vae, text_encoders, or a nested path like loras/<subdir>).

Do NOT shell out to curl/wget/aria2 for model files — a raw shell download has no progress in the panel and can drop the file in the wrong place. Reserve the shell for things download_model cannot do.

Hardware and runtime stats

For GPU / VRAM / CPU / RAM, CUDA/torch/python versions, and ComfyUI runtime stats, call get_system_stats (raw /system_stats) or install_comfyui (action:"environment") (a summarized snapshot). Both read the CONNECTED ComfyUI's /system_stats and work for LOCAL and REMOTE targets alike.

Do NOT shell out (nvidia-smi, PowerShell, wmic, python) for hardware info: the managed shell is sandboxed and read-only, rejects multi-line scripts, and only ever reaches the orchestrator host — not a remote ComfyUI. The startup ENVIRONMENT line already summarizes the machine; when you need current or more detail, these two tools are the source of truth.