Skip to main content
Glama

watch_pie_property

Destructive

Arm before PIE starts, then sample one or more Unreal properties during play to record value changes, including BeginPlay writes. Use it to observe runtime behavior, not find the writer.

Instructions

Sample one or SEVERAL properties across a PIE session, arming BEFORE PIE starts so a write that happens in BeginPlay is still observable. Answers "what did this value do during play", NOT "who wrote it": it SAMPLES rather than intercepting writes, so identifies_writer is always false and a transient A->B->A between two samples is invisible. THE ORDER MATTERS: action="start" arms and returns immediately (it cannot block the game thread), THEN you start PIE, and afterwards action="status" returns the recorded samples. Arming while PIE is ALREADY running is honoured but flagged (armed_while_pie_running) -- the BeginPlay window has already passed for that session, which is precisely the failure this tool exists to avoid, so stop PIE, arm, then start PIE. It self-disarms on duration_seconds or max_samples (it can never leak a ticker) and the recorded samples survive until action="clear".

Returns: { action: string, watch_id?: int, armed?: bool, watches: [{ watch_id, property_name, class_name, actor_label, component, sample_interval_seconds, duration_seconds, max_samples, active, saw_pie_world, armed_while_pie_running, sample_count, elapsed_real_seconds, stop_reason, distinct_objects_seen, samples?: [{ phase, object_path, actor_label, value_text, value, elapsed_real_seconds, world_time_seconds, world, changed_from_previous }] }], identifies_writer: bool, sampling_only: bool, armed_pre_pie?: bool, pie_running?: bool, class_resolved?: bool, hint?: string, world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }. The five world_* / net_mode / pie_instance fields identify the PIE world the ticker is sampling AT THE MOMENT OF THE CALL (all null / pie_instance -1 when no PIE session is running, which is the normal state right after arming).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoOptional: "start" (default) | "status" | "stop" | "clear" | "list".
watch_idNoTarget watch for "status" / "stop" / "clear" (omit = all of them).
componentNoOptional component name: sample the property on that component of the matched actor instead of on the actor.
class_nameNoOptional actor class filter (exact UClass name; a Blueprint class needs the "_C" suffix). At least one of class_name / actor_label is required for "start".
propertiesNoOptional array of property names sampled TOGETHER, in the SAME tick, as one ROW. This is what answers correlation questions ("movement_mode changed in the same tick immersion crossed the threshold"), which N separate watches cannot: each would dedupe on its own clock and the columns would not line up. The row is the dedup unit -- if ANY field changes the whole row is recorded -- and each sample carries a `values` object with the per-property breakdown. With one property there is no `values` object.
actor_labelNoOptional actor filter, matched against the editor label OR the object name.
max_samplesNoOptional hard cap on recorded samples (default 400).
property_nameNoProperty to sample on the matched object. Required for "start" unless `properties` is given.
duration_secondsNoOptional auto-disarm after this many real seconds (default 300; 0 = no time cap, disarms only on max_samples or an explicit stop).
sample_interval_secondsNoOptional periodic sampling interval (default 0.1, min 0.01).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give generic safety hints; the description supplies the substantive behavioral facts an agent needs: identifies_writer is always false, sampling (not interception) means a transient A->B->A is invisible, arming cannot block the game thread, the ticker self-disarms and cannot leak, and samples persist until action="clear".

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?

Purpose is front-loaded and the must-do ordering rule is prominent, but the prose is heavy with parentheticals and an exhaustive Returns enumeration. Dense and slightly padded, though most sentences carry genuine operational information rather than filler.

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?

There is no output schema, so the description carries the burden of documenting returns, and it does so thoroughly (full response shape with watch fields, samples array, and the world_* fields). Combined with the workflow and behavioral notes, nothing essential for correct invocation or interpretation is missing.

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 baseline is 3, but the description adds real meaning on top: it explains the action ordering semantics, the fact that max_samples/duration_seconds drive auto-disarm, and that omit-watch_id means all watches. The properties-array correlation semantics are also clarified beyond the schema text.

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 gives a specific verb and resource (sample properties over a PIE session) and immediately disambiguates from the nearest conceptual sibling by stating it answers "what did this value do" and NOT "who wrote it". An agent can tell what it does and what it is not without opening the 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?

It gives an explicit ordered workflow (action="start" arms, THEN start PIE, then action="status"), explicitly warns against the failure mode of arming while PIE is already running, and states when the alternative of a writer-identifying tool applies. When-to-use and when-not are both spelled out.

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