Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

find_blueprint_node_references

Read-onlyIdempotent

Locate every Blueprint node referencing a symbol (variable, function, event, etc.) across a content path, returning each hit's asset, graph, and node details.

Instructions

"Find in Blueprints" over MCP: locate every Blueprint NODE that references a symbol -- variable, function, event, custom event, multicast delegate, macro, timeline, cast target, component, or a class/object in a pin default -- across a content path, returning each hit's asset, graph chain, node_id, title, match_kind and RESOLVED declaring class (resolved:false = a name-only guess). READ-ONLY. THE RULE FOR READING A ZERO: matches_found:0 only measures NON-EXISTENCE when assets_hit_prefilter_without_graph_match comes back EMPTY -- if it names assets, the symbol's string IS in those packages, so either the real name is spelled differently or the reference lives outside a graph (component template, property default). Check coverage_complete too: a truncated, timed-out or capped scan proves nothing. Blind by construction: Level Script Blueprints inside a .umap, and C++ callers.

Returns: { symbol, mode, mode_recognized, path, recursive, prefilter_enabled, component_class, component_declared_in, assets_in_path, assets_scanned, assets_prefiltered_out, assets_prefilter_unavailable, assets_prefilter_bypassed_dirty, assets_loaded, assets_load_failed, assets_with_matches, graphs_visited, nodes_visited, foreign_subgraphs_skipped, matches_found, truncated, timed_out, coverage_complete, elapsed_ms, assets_hit_prefilter_without_graph_match:[string], notes:[string], matches:[{asset_name, asset_path, package_name, graph, graph_chain, graph_kind, node_id, node_class, node_title, match_kind, member_name, declaring_class, resolved, is_component_ref, is_interface_call, exact, detail, pin, pin_value, node?}], success }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoOptional (default "auto"): auto|all|variable|function|event|delegate|macro|component|class|pin_default. Filters which match kinds are returned; an unrecognized value returns everything and sets mode_recognized=false.
pathNoOptional (default "/Game"): content path root to scan.
symbolNoRequired (unless component_name is given): the name to look for, matched EXACTLY (variable/function/event/macro/class/component name). A misspelling returns 0 with a full-coverage report -- see assets_hit_prefilter_without_graph_match before believing it.
prefilterNoOptional (default true): byte-scan the .uasset name map before loading. Turning it OFF loads every Blueprint under path (slow, but the ground truth to compare against).
recursiveNoOptional (default true): recurse into subfolders of path.
asset_pathNoAlias of `path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `path`.
max_assetsNoOptional (default 20000): hard cap on candidate assets examined.
max_matchesNoOptional (default 200): stop after this many matches (sets truncated=true).
max_secondsNoOptional (default 60): wall-clock budget; on expiry the scan stops and timed_out=true.
search_termNoAlias of `symbol` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `symbol`.
include_pinsNoOptional (default false): when include_node_json is on, include the node's pins.
exclude_pathsNoOptional: array of package-path prefixes to skip (e.g. ["/Game/VendorPack/Demo"]).
function_nameNoAlias of `symbol` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `symbol`.
include_pathsNoOptional: array of package-path prefixes to restrict the scan to (applied after path).
case_sensitiveNoOptional (default false): case-sensitive symbol matching (both the byte prefilter and the node classifier).
component_nameNoOptional: search for an actor COMPONENT by name; implies mode="component" and, with owner_blueprint, also matches GetComponentByClass/Cast pins that target the component's class.
owner_blueprintNoOptional: Blueprint that DECLARES component_name (asset name or path); required to resolve the component's class for the class-pin matching.
include_node_jsonNoOptional (default false): embed the full NodeToJson serialization of each matching node.
include_pin_defaultsNoOptional (default true): also report pin defaults / pin types that name the symbol, on nodes with no structural match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: declared blind spots (Level Script Blueprints in a .umap, C++ callers), truncation/timeout/coverage semantics, and that resolved:false means a name-only guess. This is exactly the extra disclosure that a lower-bar-with-annotations case rewards.

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?

Front-loaded with the core purpose and the critical zero-result rule before any detail. The full Returns enumeration is long, but since there is no output schema it substitutes for one and largely earns its place; the density is justified even if the prose could be tightened.

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 19-param tool with no output schema, the description covers result interpretation, truncation/coverage caveats, resolution semantics, blind spots, and the output field set. An agent has everything needed to call it and to correctly read a zero-result response.

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 19 parameters, including the aliases and defaults. The description adds little parameter-level meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource+scope: locate every Blueprint NODE referencing a symbol (variable, function, event, macro, class, component, pin default) across a content path, returning asset/graph/node_id/title/match_kind. This is clearly distinguishable from sibling asset-level tools like get_asset_referencers or get_asset_dependents, which operate on assets rather than graph nodes.

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?

Gives strong operational guidance: the rule for interpreting matches_found:0 relative to assets_hit_prefilter_without_graph_match, the need to check coverage_complete, and the prefilter on/off tradeoff. It does not, however, explicitly name sibling alternatives (e.g. asset-level referencers) to route the agent elsewhere, so it stops short of a 5.

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

Deploy Server

Other Tools