Skip to main content
Glama
aadeshrao123

Unreal-MCP

by aadeshrao123

performance_analyze_insight

Query loaded .utrace profiling data to diagnose performance problems: find bottlenecks, spikes, hot paths, and compare frame times.

Instructions

Query profiling data from a loaded .utrace trace.

RECOMMENDED WORKFLOW (compact output, saves context):

  1. "diagnose" — ONE CALL full report: verdict, findings, categories, top timers

  2. "spikes" — Auto worst frames + category breakdown

  3. "flame" — Top timers by exclusive (self) time — actual bottleneck code

  4. "hotpath" — Drill into a category or event's children

  5. "search" — Find a timer across all frames (stats + worst frames)

  6. "histogram" — Frame time distribution (periodic hitches vs sustained?)

  7. "compare" — Compare frame vs trace median, show outlier events

Use performance_start_trace/stop_trace to record and auto-load a trace, or use query="load" to load an existing .utrace file.

Args: query: Type of analysis. One of:

    SMART QUERIES (compact output, do analysis in C++):
    - "diagnose"      — ONE CALL full performance report. Returns: verdict string,
                        severity-rated findings with recommendations, category
                        breakdown (avg per-frame exclusive ms), top 10 exclusive
                        timers, GPU-bound detection. Start here.
    - "bottlenecks"   — Auto-categorize frame into Animation/Slate/Network/etc
                        with total time per category and top event. VERY compact.
    - "hotpath"       — Drill into a category or event's children, sorted by time
    - "compare"       — Compare frame vs trace median, show outlier events only
    - "spikes"        — Auto worst frames + category breakdown (combines worst_frames
                        + bottlenecks). Shows top 3 categories per spike frame.
    - "search"        — Find a timer across ALL frames. Returns min/avg/max/p95/p99
                        stats + worst frames list. Use filter= for timer name.
    - "histogram"     — Frame time distribution. Shows bucket counts + budget
                        summary (on-budget / slightly over / 2x / 4x over).
    - "flame"         — Top timers by EXCLUSIVE (self) time. Shows per-frame avg
                        exclusive ms, self_pct (excl/incl ratio), category label.
                        Answers "what code actually consumes the most CPU?"

    STANDARD QUERIES:
    - "load"          — Load an existing .utrace file (requires trace_path)
    - "summary"       — Overview: duration, frame count, avg/min/max/p95 frame time
    - "worst_frames"  — Find the slowest frames with top events
    - "frame_details" — Per-thread timing breakdown for one frame (use bottlenecks first!)
    - "timer_stats"   — Aggregated stats for timers (top N by inclusive time)
    - "butterfly"     — Callers/callees for a specific timer (requires timer_name)
    - "threads"       — List all threads in the trace
    - "counters"      — List counters (GPU memory, draw calls, etc.)

    PROVIDER QUERIES:
    - "net_stats"     — Network profiling (needs 'net' channel)
    - "loading"       — Asset loading analysis (needs 'loadtime' channel)
    - "logs"          — Log messages (needs 'log' channel)
    - "memory"        — LLM memory tags (needs 'memtag' channel)
    - "regions"       — Timing regions (needs 'region' channel)
    - "bookmarks"     — Bookmark events (needs 'bookmark' channel)

    EXTENDED PROVIDER QUERIES:
    - "session"       — Session metadata: platform, app, project, build version,
                        branch, changelist, config, target type. Essential context.
    - "modules"       — Loaded modules/DLLs with symbol resolution stats.
                        Shows resolved/failed/pending counts per module.
    - "file_io"       — File I/O activity: per-file read/write counts, bytes,
                        duration. Sorted by impact. Needs 'loadtime' channel.
    - "tasks"         — Task graph: task lifecycle (created→finished), duration,
                        wait time, prerequisites, nested tasks. Sorted by duration.
    - "context_switches" — CPU core scheduling: core count, per-thread context
                        switch frequency. Needs elevated/admin trace.
    - "allocations"   — Memory allocation timeline: peak/min memory, live alloc
                        count, alloc/free events, heaps, swap. Needs 'memalloc'.
    - "stack_samples" — CPU sampling profiler: flat profile of hotspot functions
                        by sample count with percentage. Needs sampling enabled.
    - "screenshots"   — Screenshot metadata captured during trace recording.
                        Needs 'screenshot' channel.

trace_path: (load) Absolute path to a .utrace file
frame_index: (bottlenecks, hotpath, compare, frame_details) Which frame (0-based)
target_fps: (bottlenecks, spikes, histogram) Target FPS for budget (default: 60)
category: (hotpath) Category to drill into: Animation, Slate, Network, Physics,
          Rendering, Gameplay, Audio, Loading, GarbageCollection, Other
event_name: (hotpath) Specific event name to show children of
min_deviation_pct: (compare) Min deviation % to report (default: 50)
thread: (bottlenecks, hotpath, compare, spikes, search) Thread (default: GameThread)
count: (worst_frames, spikes, search, timer_stats, hotpath, file_io, tasks,
          modules, stack_samples) Max results
threshold_ms: (worst_frames, spikes) Only show frames slower than this
max_depth: (frame_details, butterfly, hotpath) Max call stack depth
min_duration_ms: (frame_details) Hide events shorter than this
thread_name: (frame_details) Filter to threads containing this string
filter: (search, timer_stats, counters, logs, memory, regions, bookmarks,
          modules, file_io, tasks, stack_samples) Name/path filter
start_time: Start of time range in seconds (-1 = trace start)
end_time: End of time range in seconds (-1 = trace end)
include_values: (counters) Include sampled values
max_samples: (counters) Max value samples per counter
timer_name: (butterfly) Function/scope name to analyze
mode: (butterfly) "callers", "callees", or "both"
connection_index: (net_stats) Connection index for packet details
verbosity: (logs) Filter: Fatal, Error, Warning, Display, Log, Verbose
tracker: (memory) Memory tracker ID
bucket_size_ms: (histogram) Custom bucket width in ms (0 = auto based on target_fps)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoboth
countNo
queryYes
filterNo
threadNo
trackerNo
categoryNo
end_timeNo
max_depthNo
verbosityNo
event_nameNo
start_timeNo
target_fpsNo
timer_nameNo
trace_pathNo
frame_indexNo
max_samplesNo
thread_nameNo
threshold_msNo
bucket_size_msNo
include_valuesNo
min_duration_msNo
connection_indexNo
min_deviation_pctNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description carries full burden and excels. It discloses behavioral traits such as output characteristics ('compact output', 'ONE CALL full report'), query-specific behaviors (e.g., 'returns: verdict string, severity-rated findings'), and parameter effects. There is no contradiction with absent annotations, and the tool's read-only nature is implied by its analytic purpose.

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 description is lengthy but well-structured: a recommended workflow, then query types organized into groups, then parameter listings. While every sentence serves a purpose, there is some redundancy (query types listed both in the workflow and later in full). The front-loading of the workflow is good, but a slightly more concise presentation could improve readability without losing clarity.

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 complexity (24 parameters, many query types) and the presence of an output schema, the description is fully complete. It covers all query modes, parameter associations, and return value hints. It also references sibling tools for trace recording, providing a complete picture of the tool's role in the larger workflow.

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%, but the description's 'Args:' section adds rich meaning beyond the schema. Each parameter is paired with the queries that use it and a clear description of its role (e.g., 'frame_index: (bottlenecks, hotpath, compare, frame_details) Which frame (0-based)'). Defaults are also mentioned, compensating fully for the lack of 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 clearly defines the tool as analyzing profiling data from a .utrace trace, with an explicit verb ('Query profiling data') and resource ('loaded .utrace trace'). It distinguishes itself from sibling tools like performance_start_trace and performance_stop_trace by focusing on analysis after a trace is loaded, and the recommended workflow references those sibling tools for recording.

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?

The description provides a detailed recommended workflow (the 7-step sequence) and explicitly states when to use each query type (e.g., 'Start here' for 'diagnose'). It also advises on when to use performance_start_trace/stop_trace or query='load' to obtain the trace file, giving clear context on alternatives.

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/aadeshrao123/Unreal-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server