Skip to main content
Glama

capture_pie_state

Destructive

Snapshot every actor and its replicated or SaveGame properties in a live PIE world for a chosen client index, proving whether values actually replicate in co-op sessions.

Instructions

Snapshot of every actor in the ACTIVE PIE world, with every property flagged Replicated or SaveGame (generic -- no judgment call about what is "relevant"). It requires a live PIE session: with none running for pie_client_index it errors cleanly instead of silently snapshotting the EDITOR world, which is what makes it usable as co-op evidence -- point it at a client index to prove a value really replicated. On a large world ALWAYS pass class_filter and/or max_actors. Returns a summary plus a report path; read the detail with read_mcp_audit_file.

Returns: { path: string, truncated: bool, summary: { actor_count: int, actors_seen: int, total_matching_actors: int, max_actors: int, truncated: bool, class_filter: [string], replicated_property_count: int, savegame_property_count: int, savegame_filter_status: "active"|"dead_in_this_run" }, report_size_bytes: int, verification: {...}, verification_checks: [...] } -- class_filter lists the resolved class paths; success is false when the report is missing or empty on disk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_actorsNoOptional cap on how many actors get their properties reflected into the report; 0 (the default) means UNLIMITED, and negative values are clamped to 0. Actors past the cap are still COUNTED (cheap) but not reflected (the expensive part), so total_matching_actors and truncated are exact, not estimated.
class_filterNoOptional actor-class guardrail. Accepts a single class name OR an array of them (the hint is deliberately absent: the type-hint grammar has no union, and `[string|array]` would make this whole @param unparseable, leaving it an EMPTY description in the catalog). Detail: one class name or an array of them, each resolved to a UClass (object/script path, short name, or the Blueprint asset name -- "<Name>_C" is tried too) and matched with IsA, so subclasses match. An entry that does not resolve, or that resolves to a non-AActor class, is a hard ERROR rather than being dropped: dropping it would silently snapshot the whole World Partition world, keeping it would silently return an empty snapshot. Defaults to no filter (every actor).
pie_client_indexNoWhich PIE client's world to snapshot (0 = first/server/standalone). Defaults to 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true / readOnlyHint=false, and the description supplies the behavior they don't: it requires a live PIE session, errors instead of silently capturing the editor world, warns about large worlds, and discloses that it produces an on-disk report ("Returns a summary plus a report path"). The tension between the evidence-gathering framing and destructiveHint=true is left unexplained -- the description never says what the write side effect is -- so it is good but not fully transparent.

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, prerequisites, scaling guardrail, and return artifact are front-loaded in that order, and the return-shape block earns its space because there is no output schema. It is dense and long, but nearly every sentence carries distinct information.

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, the description fully documents the return contract (path, truncation semantics, summary counters, savegame_filter_status, verification, success semantics), plus the PIE precondition and the performance guardrail. Nothing needed to invoke or interpret the call 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, and the description adds genuine usage semantics on top: point pie_client_index at a client to prove a value replicated, and always pass class_filter and/or max_actors on large worlds. It does not add format or syntax detail beyond the (already very verbose) schema entries.

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 opening sentence names a specific verb and resource (snapshot every actor in the ACTIVE PIE world) and the payload (properties flagged Replicated or SaveGame), which immediately separates it from editor-world or generic object snapshots in the sibling set. It also states the scope qualifier ("generic -- no judgment call about what is relevant") so the agent knows exactly what it gets.

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?

Strong context: it must be run against a live PIE session, errors cleanly rather than silently falling back to the EDITOR world, and is intended as co-op replication evidence, with an explicit scaling rule ("ALWAYS pass class_filter and/or max_actors"). It routes follow-up reading to read_mcp_audit_file but never explicitly contrasts itself with closely related siblings such as snapshot_object or diff_object_snapshots, so it stops short of full alternative routing.

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