Skip to main content
Glama

net_get_replication_graph_state

Inspect the current replication graph and net driver state for the active Unreal world, with a configurable sample of actors, to diagnose network synchronization problems.

Instructions

Inspect runtime replication graph/net driver state for the active world.

Args: max_actors: Maximum replicated actor samples to include.

KB: see knowledge_base/20_NETWORKING_AND_REPLICATION.md#mcp-network-tools Example: net_get_replication_graph_state(max_actors=10)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_actorsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. The word 'Inspect' clearly signals a non-mutating operation, and 'runtime ... for the active world' adds the key precondition that a live world context must exist. It does not go deeper into failure modes or side effects, but for a read-only inspection tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, followed by an Args section, a KB pointer, and a concrete example. Every line earns its place with no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return-value details are covered elsewhere. The one parameter is adequately documented, and the example plus KB reference round out the picture. It stops short of stating prerequisites such as requiring a running PIE session, but 'runtime ... active world' strongly implies the context.

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%, so the description must compensate for the single parameter. It does: 'Maximum replicated actor samples to include' adds real meaning beyond the property name and type, and the example call demonstrates expected invocation syntax.

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 states a specific verb ('Inspect') and a specific resource ('runtime replication graph/net driver state') scoped to 'the active world'. This clearly distinguishes it from sibling configuration tools like net_set_actor_replicates and net_configure_replicated_property.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is a read-only inspection tool for runtime networking state, but it does not explicitly state when to use it over alternatives like network_debug_replication or net_describe_blueprint_replication. The KB reference and example provide some context, but no explicit when/when-not guidance.

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