Skip to main content
Glama

get_graph_nodes

Read-onlyIdempotent

Reads the nodes, pins and links of a Blueprint, material, MetaSound or Control Rig graph without modifying it, so you can inspect topology or fetch one node's full pin data.

Instructions

Read the nodes of one graph without changing it: a Blueprint graph (Animation and Widget Blueprints included), or the graph of a material, material function, sound cue, MetaSound Source, PCG graph or Control Rig. It is the read behind add_graph_node, connect_pins and set_pin_default_value, and the way to see what a graph does.

Every node has its node_id, which the graph tools take, and its object_path (not in a MetaSound), which get_object_info and set_properties take for the node's own settings. A Blueprint node also lists its class, title, position, comment and pins with their links and defaults; another asset answers with its editor's own view, named by graph_kind.

Read a graph, then one node: {"asset_path": "/Game/Blueprints/BP_Door", "compact": true} for the topology, then the same asset_path with "node_id" for every pin of one node. compact leaves out unlinked pins without a default, so a pin missing from a compact listing may still exist: check it by node_id. graph_name picks another graph of a Blueprint, a collapsed graph by its title included, and expand_composites inlines the collapsed graphs instead.

It reads the graph as the editor holds it, unsaved edits included, loading the asset from disk if needed, and compiles nothing, so a Blueprint that fails to compile still lists its nodes. A large graph costs many tokens: max_nodes caps the reply, and truncated says whether nodes were left out. Reading a graph under a read-only vendor root leaves its package dirty in memory; reload_asset_package with on_dirty="discard" cleans it.

Returns: { blueprint_name, graph_name, nodes: [{ node_id, object_path?, class, title, pos_x, pos_y, comment, pins: [...], subgraph? }], node_count, compact, total_node_count, excluded_count, truncated, graph_kind? } -- node_count counts the nodes returned and total_node_count those that exist; a node holding a nested graph has subgraph, the graph_name to read it with. Another asset: its editor's view, a MetaSound's links in connections.

Input Schema

NameRequiredDescriptionDefault
compactNoToken-lean listing: drops pin types, positions and comments, and skips pins that are unlinked AND have no default. Also excludes K2Node_Knot + EdGraphNode_Comment unless exclude_classes is given. Good for reading topology, WRONG for checking whether a pin exists. (Optional, default false)
node_idNoOptional node_id (from add_graph_node / get_graph_nodes): return ONLY that node, in a Blueprint always at full fidelity (compact, exclude_classes, expand_composites and max_nodes are ignored) -- every pin with name, direction, type, linked_to and default, at a fraction of the tokens of a whole graph. A node_id the graph does not contain is an error.
max_nodesNoCap on the number of nodes emitted (<=0 or absent = unlimited); the response still counts every non-excluded node in total_node_count and sets truncated=true.
asset_pathNoThe graph asset: a Blueprint by name or path, or the path of a material, material function, sound cue, MetaSound Source, PCG graph or Control Rig. Prefer the FULL path: a Blueprint short name with more than one match resolves silently to one of them, and stale backup copies share the original's name.
graph_nameNoBlueprint only: the graph, default the event graph ("AnimGraph" for an Animation Blueprint's anim graph). Also resolves a collapsed composite subgraph by its title (e.g. 'In Game HUD') and accepts a path form ('EventGraph > In Game HUD'). The other assets have one graph: leave it out.
blueprint_nameNoOlder name of asset_path, still accepted.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
exclude_classesNoArray of leaf node class names to skip, matched against each node's "class" field (e.g. ["K2Node_Knot"]). Pass [] to include everything even in compact mode. Absent + compact=true means knots and comments are excluded; absent + compact=false excludes nothing.
expand_compositesNoWhen true, inline the nodes of collapsed composite subgraphs recursively; each node gains a "graph" tag naming the graph it came from. Macro-library graphs are never inlined. (Optional, default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.5.0
    • addedInput schema / properties / asset_path
      Added value: +{
      +  "description": "The graph asset: a Blueprint by name or path, or the path of a material, material function, sound cue, MetaSound Source, PCG graph or Control Rig. Prefer the FULL path: a Blueprint short name with more than one match resolves silently to one of them, and stale backup copies share the original's name.",
      +  "type": "string"
      +}
    • changedInput schema / properties / blueprint_name / description
      Previous value: -"Blueprint asset name or path. Prefer the FULL path: a short name with more than one match resolves silently to one of them, and stale backup copies share the original's name."New value: +"Older name of asset_path, still accepted."
    • changedInput schema / properties / graph_name / description
      Previous value: -"Target graph name; defaults to the Blueprint's event graph when omitted. Also resolves a collapsed composite subgraph by its title (e.g. 'In Game HUD') and accepts a path form ('EventGraph > In Game HUD')."New value: +"Blueprint only: the graph, default the event graph (\"AnimGraph\" for an Animation Blueprint's anim graph). Also resolves a collapsed composite subgraph by its title (e.g. 'In Game HUD') and accepts a path form ('EventGraph > In Game HUD'). The other assets have one graph: leave it out."
    • changedInput schema / properties / node_id / description
      Previous value: -"Optional NodeGuid (from add_graph_node / get_graph_nodes): return ONLY that node of the graph, always at full fidelity (compact, exclude_classes, expand_composites and max_nodes are ignored) -- every pin with name, direction, type, linked_to and default, at a fraction of the tokens of a whole graph. A node_id the graph does not contain is an error."New value: +"Optional node_id (from add_graph_node / get_graph_nodes): return ONLY that node, in a Blueprint always at full fidelity (compact, exclude_classes, expand_composites and max_nodes are ignored) -- every pin with name, direction, type, linked_to and default, at a fraction of the tokens of a whole graph. A node_id the graph does not contain is an error."
  2. Changed1 schema field changedv2.0.0
    • addedInput schema / properties / node_id
      Added value: +{
      +  "description": "Optional NodeGuid (from add_graph_node / get_graph_nodes): return ONLY that node of the graph, always at full fidelity (compact, exclude_classes, expand_composites and max_nodes are ignored) -- every pin with name, direction, type, linked_to and default, at a fraction of the tokens of a whole graph. A node_id the graph does not contain is an error.",
      +  "type": "string"
      +}
  3. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses that it reads unsaved editor state, loads from disk if needed, compiles nothing, and still lists nodes for uncompilable Blueprints. It also explains token costs, max_nodes/truncated behavior, and the dirty-package side effect under read-only vendor roots with a cleanup path.

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 purpose and then proceeds through node identity, read workflow, runtime behavior, and return shape in a logical order. Despite its density, the detail is earned by the tool's complexity and the absence of an output schema.

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?

For a complex nine-parameter read tool with no output schema, the description is complete: it covers supported assets, workflow, parameter interactions, truncation, side effects, and the exact return shape. Nothing material is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all nine parameters in detail. The description adds meaningful usage context beyond schema text, especially the two-step asset_path/node_id workflow and how object_path is consumed by get_object_info and set_properties, though much parameter detail is duplicated.

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 first sentence states a specific verb and resource: 'Read the nodes of one graph without changing it.' It enumerates the supported graph/asset types and identifies the tool as the read operation behind add_graph_node, connect_pins, and set_pin_default_value, clearly distinguishing it from those sibling mutation tools.

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?

It gives explicit workflow guidance: read the graph with compact=true for topology, then read one node by node_id for full pin detail. It also warns when compact is wrong, explains graph_name and expand_composites, and points to get_object_info/set_properties for node settings.

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