Skip to main content
Glama

trace_blueprint_execution

Read-onlyIdempotent

List a Blueprint's graphs and nodes for static analysis, with graph counts, functions, and events; use breakpoints instead to observe runtime execution.

Instructions

STATIC listing of a blueprint's graphs and their nodes. It does NOT trace anything at runtime, despite the name: trace_status reports "StaticAnalysisOnly", and total_execution_paths does NOT count execution paths -- it counts GRAPHS, kept under that name only for compatibility, alongside the honest alias graphs_analyzed and the flag total_execution_paths_is_graph_count. Collapsed composite subgraphs are invisible unless you pass include_composites=true. TO ACTUALLY OBSERVE RUNTIME use set_blueprint_breakpoint (+ PIE) or watch_pie_property instead.

Returns: { blueprint_path: string, resolved_object_path: string, blueprint_class: string, trace_status: string, trace_level: string, trace_message: string, file_size_bytes: int, file_size_mb: number, total_execution_paths: int, graphs_analyzed: int, total_execution_paths_is_graph_count: bool, is_static_analysis: bool, traced_runtime: bool, includes_composite_subgraphs: bool, limitations: [string], function_count: int, event_count: int, execution_flow: [string], function_calls: [string], event_calls: [string], blueprint_compiled: bool, compilation_status: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
blueprint_nameNoAlias of `blueprint_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_path`.
blueprint_pathNoObject path, package path, or bare short name of the blueprint (resolved via mcp_common::ResolveAssetFlexible; ambiguity errors out listing candidates)
include_compositesNoOptional (default false): also descend into collapsed composite subgraphs (UEdGraph::SubGraphs). Macro-instance graphs are NOT followed (they usually live in another Blueprint / an engine macro library).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish the safe read-only/idempotent profile, but the description adds behavior annotations cannot express: that trace_status reports 'StaticAnalysisOnly', that total_execution_paths counts graphs not paths, and that collapsed composite subgraphs are invisible unless include_composites=true. These are exactly the kind of non-obvious traits that prevent wrong agent conclusions.

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 naming caveat is correctly front-loaded in the first sentence, and the alternatives sentence is tight. The full field-by-field Returns block is lengthy, though defensible since no output schema exists; it is the only section that could be trimmed.

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?

With no output schema, enumerating the return fields (trace_status, graphs_analyzed, total_execution_paths_is_graph_count, limitations, etc.) is genuinely necessary and supplied. Naming traps, the composite limitation, and the runtime alternatives are all covered, leaving nothing an agent needs missing.

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% and each parameter (blueprint_name alias, blueprint_path resolution, include_composites) is fully documented in the schema. The description reiterates the include_composites gate and its macro-instance caveat, so it is marginally useful but adds no syntax or format meaning beyond the schema. 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 and resource ('STATIC listing of a blueprint's graphs and their nodes') and immediately disambiguates the misleading verb 'trace' by declaring it does NOT trace at runtime. An agent can tell it apart from the runtime tracing siblings without opening any schema.

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?

Explicitly routes the agent: 'TO ACTUALLY OBSERVE RUNTIME use set_blueprint_breakpoint (+ PIE) or watch_pie_property instead.' It names both alternatives and the condition that selects them, so there is nothing left to infer.

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