Skip to main content
Glama

get_workspace_graph

Read the workflow currently open in the browser, including unsaved edits, to answer questions about the on-screen graph, selected nodes, and connections.

Instructions

Read the workflow currently open in the browser, unsaved edits included.

This is the one view of a workflow that no file and no HTTP endpoint can give: what the user is actually looking at. Use it to answer questions about the graph on screen; use describe_workflow for the files in the workflows directory.

The summary reports selected - the nodes and groups the user has clicked on. Treat it as them pointing: when a request says "this one" or "these", that is which ones, and it beats guessing from a title. set_workspace_selection points back the other way.

A large workflow does not fit in one answer at any detail that includes its wiring, so the report steps down a level at a time until it does and says so in reduced. When that happens the next move is only - outline the whole graph, then ask again about the handful of nodes that matter. Each node in a subset also carries feeds, the nodes reading from it, so a subset can be walked downstream as well as up.

Args: format: "summary" for a structured report - nodes, links, groups and a list of issues (missing node types, muted or bypassed nodes, unconnected required inputs). "ui" for the raw graph as a Save would write it. "api" for the API-format prompt, the same JSON that Export (API) and run_workflow use - only the frontend can produce it, which is why it is available here and nowhere else in this server. scope: "root" for the top level of the workflow, "active" for the subgraph on screen, "all" to descend into every subgraph. On a workflow built from subgraphs "root" is a handful of boxes and everything inside them is invisible, so reach for "all" when the question is about the whole thing. Nested nodes come back with path ids - 98:12 is node 12 inside subgraph node 98 - the same shape the API format and progress events use. Only "summary" descends; "ui" and "api" already cover the lot. detail: how much to say about each node. "full" is everything including widget values; "links" drops the widgets but keeps the wiring and positions; "outline" is one line per node - type, title, and how many links go in and out. Only a ceiling: a report over COMFYUI_GRAPH_MAX_CHARS is reduced further whatever was asked for. only: report just these node ids, at the detail asked for, however big the graph is. Pass "selected" for whatever the user has clicked on. client_id: which tab to ask; defaults to the most recently focused one. workspace_status lists them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
onlyNo
scopeNoroot
detailNofull
formatNosummary
client_idNo

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 provided, the description fully carries the burden and excels. It discloses unsaved edits inclusion, the 'reduced' step-down behavior for large graphs, the 'api' format being frontend-only, scope semantics with path ids, and the ceiling behavior of detail. This goes well beyond what annotations could provide.

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 every sentence earns its place. It front-loads the core purpose and then systematically explains parameters and edge cases. The 'Args' section is well-structured and avoids fluff.

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 (5 params, 0% schema coverage, no annotations), the description is remarkably complete. It explains return formats, reduction semantics, subset walking with 'feeds', and the unique api format value. The presence of an output schema reduces the need to describe return structures, and the description covers everything else needed 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%, yet the description explains all five parameters in depth: format with three distinct return types, scope with examples and nested-node path ids, detail with three levels and ceiling behavior, only with the special 'selected' value, and client_id with default and listing source. This fully compensates for the missing schema descriptions.

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: 'Read the workflow currently open in the browser, unsaved edits included.' It clearly differentiates itself from siblings by stating 'use describe_workflow for the files in the workflows directory' and emphasizes its unique ability to report what the user is looking at.

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 usage guidance is provided: when to use this tool vs describe_workflow, how to interpret 'selected' as pointing during user requests, when to use 'only' for reduced large graphs, and how set_workspace_selection points back the other way. This covers both when and when-not to use it.

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