Skip to main content
Glama

ue5_read_nodes

Read blueprint nodes to retrieve titles, positions, GUIDs, and pin defaults, optionally searching all graphs when no graph name is given. Use it to gather GUIDs before connecting pins.

Instructions

Read Blueprint nodes: titles, positions, GUIDs and pin defaults. Omit graph_name to search all graphs. Use before connecting pins so you have the GUIDs. | 读取蓝图节点(不传 graph_name = 全图搜索)。

Input Schema

NameRequiredDescriptionDefault
fieldsNoKeep only these fields | 只返回指定字段
bp_pathYesBlueprint asset path, e.g. /Game/BP_Test | 蓝图资产路径
graph_nameNoGraph name; omit to search all graphs | 图名,缺省=全图搜索

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.5.4
    • addedInput schema / properties / fields
      Added value: +{
      +  "description": "Keep only these fields | 只返回指定字段",
      +  "type": "array"
      +}
  2. Changed2 schema fields changedv3.2.1
    • addedInput schema / properties / bp_path / description
      Added value: +"Blueprint asset path, e.g. /Game/BP_Test | 蓝图资产路径"
    • addedInput schema / properties / graph_name / description
      Added value: +"Graph name; omit to search all graphs | 图名,缺省=全图搜索"
  3. First observedv3.2.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description bears the full burden. It establishes that this is a non-mutating read and lists the returned fields, but it says nothing about cost or result volume when graph_name is omitted and every graph is scanned, nor about permissions or limits on large Blueprints. The scope semantics are covered; the operational traits are not.

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 returned data is front-loaded in the first clause, followed by the graph_name caveat and the workflow tip, which is good ordering. The bilingual restatement nearly doubles the length without adding information, which is the only real waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter read tool with full schema coverage and no output schema, the description covers what is returned and how graph_name scoping works — enough to call it correctly. The unexplained 'fields' parameter and the unqualified all-graph search cost are the remaining gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters, making 3 the baseline. The description re-states the graph_name omission behavior (redundant with the schema) and never mentions the 'fields' projection parameter, so it adds little beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Read Blueprint nodes') and enumerates the returned data ('titles, positions, GUIDs and pin defaults'), so an agent knows exactly what it gets. It does not, however, distinguish itself from the sibling ue5_search_blueprint_nodes or ue5_read_blueprint, leaving genuine overlap unresolved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a concrete workflow constraint — 'Use before connecting pins so you have the GUIDs' — which tells the agent when in a sequence to call it. The graph_name omission is also framed as a search-all behavior. There is no explicit when-not or named alternative, which keeps it from a 5.

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