Skip to main content
Glama

switch_workspace_tab

Switch to a different open workflow tab in ComfyUI, optionally forcing a reload. Specify the tab by index, path, filename, or keyword, and select the target browser tab via client_id.

Instructions

List the workflow tabs open in the ComfyUI window, and switch between them.

These are the tabs along the top of ComfyUI: open workflows, exactly one of which is on screen. They are not browser tabs - one browser tab holds all of them, and client_id plus workspace_status is where that sense of the word lives.

With no to it reports and moves nothing, which is also how to find out what is open before naming one. Every other workspace tool acts on the workflow that is on screen, so this is what points them at a different one.

Switching does what clicking the tab does, and no more: the canvas is reloaded from that workflow's own stored state. Unsaved edits in the tab being left behind are not lost - they belong to that workflow, which is why a tab can report modified while a different one is on screen.

"new" opens a blank workflow and switches to it, which is the same command the + button on the tab bar runs. That is the way to start something from nothing without disturbing what the user already has open.

Args: to: which tab - an index from a previous call, its path or its filename, or "next", "previous", "recent" for the one active before this, or "new" for a fresh blank workflow. Empty reports without moving. A name matching two open tabs is refused rather than guessed. force: reload the tab already on screen instead of reporting that it is already there. client_id: which browser tab to ask; defaults to the most recently focused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
forceNo
client_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: switching reloads the canvas from that workflow's stored state, unsaved edits are not lost, 'force' reloads the current tab, and ambiguous names are refused. It even states 'Switching does what clicking the tab does, and no more', setting accurate expectations.

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 well-organized with front-loaded purpose and an Args list. While slightly verbose, every sentence adds useful context, such as clarifying how 'new' works and the relationship with workspace_status. It earns its length, though a minor trim could improve conciseness.

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 (multiple parameter value types, edge cases) and lack of annotations, the description is remarkably complete. It covers all parameters, ambiguous name handling, the 'new' action, and the interaction with other workspace tools. An output schema exists, so return values need no explanation.

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% and parameters lack descriptions, but the description's 'Args:' section fully compensates. It explains the semantics of 'to' (index, path, filename, special keywords), 'force', and 'client_id', adding rich meaning beyond the bare schema types and defaults.

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 clearly states the tool's purpose: 'List the workflow tabs open in the ComfyUI window, and switch between them.' It specifies the resource (workflow tabs in ComfyUI) and distinguishes itself from browser tabs and other workspace tools, making it unambiguous and well-differentiated from siblings.

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?

The description provides explicit usage guidance: it explains when to use the tool (to point other workspace tools at a different workflow), how to discover open tabs (call with no 'to'), and when to use 'new'. It also contrasts with 'Every other workspace tool', giving clear alternatives.

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