Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

start_play_in_editor

Destructive

Launch a real Play-in-Editor session in Unreal Engine, optionally with multiple clients and listen-server networking, to test co-op or multiplayer gameplay.

Instructions

Press Play: starts a real PlayInEditor session (a true play world with a spawned PlayerController, not SimulateInEditor), optionally multi-client and networked for co-op testing via number_of_clients + net_mode=ListenServer. WARNING: RequestPlaySession is ASYNC and this tool probes right after asking, so pie_started comes back FALSE on a start that is perfectly fine -- the oracle is a follow-up is_play_in_editor_active, never this field. With 2+ clients the worlds are UEDPIE_0 (server) and UEDPIE_1 (client), and later reads must be anchored with world='server'/'client' because PIE actor NAMES are swapped between them. Refuses if another MCP session (or a human) already owns PIE unless force=true.

Returns: { pie_started: bool (probed synchronously right after an ASYNC request -- usually false even on success; confirm with is_play_in_editor_active), already_in_pie: bool, message: string, number_of_clients: int, net_mode: string, dirty_package_count: int, readonly_dirty_count: int, dirty_packages: [string] (capped at 25), dirty_packages_truncated: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoOptional bool (default false). Override the PIE-ownership guard: start even if another session (or a manually-started PIE) currently owns Play-in-Editor. Read by the server before the tool runs, so a non-owner session can seize PIE.
net_modeNoOptional string: "Standalone"|"ListenServer"|"Client" (default "Standalone"). Any other value is a clean error, not a silent fallback. Use ListenServer for co-op.
number_of_clientsNoOptional int (default 1, clamped 1-10). >1 opens additional client windows -- that is what makes a co-op reading possible at all.
run_under_one_processNoOptional bool (default true). Must stay true for multi-client windows to open inside this single editor process.

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 declare destructive/not-readonly/not-idempotent, but the description adds far more: the async request means pie_started is usually false even on success, the ownership guard semantics, and the multi-client world naming (UEDPIE_0/UEDPIE_1) with swapped PIE actor names requiring world='server'/'client' anchoring. This is rich context the annotations cannot convey.

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?

Front-loaded with 'Press Play:' and every sentence earns its place given the async gotcha and multi-client caveats. It is a dense block rather than cleanly sectioned, but length is justified for a tool with this many hidden behaviors.

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 supplies a full Returns block (fields plus the warning that pie_started is unreliable), plus ownership, async, and multi-client details. Nothing an agent needs to invoke or interpret this tool correctly 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 per-parameter docs already carry the baseline. The description adds the interaction meaning — that number_of_clients together with net_mode=ListenServer is what makes a co-op reading possible — which the schema treats as separate params, so it exceeds the 3 baseline modestly.

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+resource ('starts a real PlayInEditor session') and immediately distinguishes it from a sibling behavior ('a true play world with a spawned PlayerController, not SimulateInEditor'). An agent can tell exactly what this does and what it is not.

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 says when to use co-op (number_of_clients + net_mode=ListenServer), when it refuses (another MCP session or a human owns PIE), and how to override (force=true). It also names the correct follow-up oracle (is_play_in_editor_active) rather than an alternative tool.

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