Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

list_objects_of_class

Read-onlyIdempotent

Enumerate live in-memory Unreal objects of any UObject-derived class, optionally scoping to one world to separate server, client, editor, or PIE results.

Instructions

Enumerate live instances of a class currently in memory, complementing get_actors_by_class (actors only) with any UObject-derived type. Accepts world to SCOPE the sweep to one world — 'server' vs 'client' is what separates an authoritative census from a replicated one, and without it a PIE session returns the instances of EVERY world mixed together (host and client both), which reads as duplicates. The response stamps the world that answered, so count:0 means "not in THIS world" instead of "does not exist".

Returns: { class_name: string, objects: [{object_path, name, class, outer}], count: int, world: string ('any' when no selector was given), world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional world selector that SCOPES the sweep: absent (default: every loaded instance, across all worlds) | 'editor' | 'pie' (ambiguous: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'game' (alias of 'pie'). Only objects whose GetWorld() IS that world are returned; an UNRECOGNIZED value is an error naming the worlds that exist, never a silent fallback to another world.
class_nameYesName/path of the class to enumerate instances of (resolved via ResolveClass)
world_onlyNoOnly include objects that resolve a UWorld via GetWorld() (default true). Ignored when `world` is given, which is already a stricter filter.
include_defaultNoInclude each class's Class Default Object (default false). A CDO has no world, so passing `world` excludes CDOs regardless of this flag.

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 already declare the read-only, idempotent, non-destructive profile, so the bar is lower. The description adds real behavioral value beyond that: how world-scoping changes results, that an unscoped PIE sweep reads as duplicates, and that count:0 means 'not in THIS world' rather than 'does not exist'.

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 purpose followed by the scoping constraint, and every clause carries information. The world paragraph is dense with em-dash asides and could be tightened, but nothing is 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?

No output schema exists, but the description supplies the full return shape (class_name, objects, count, world fields, net_mode, pie_instance), so an agent knows exactly what it gets back. Combined with the world-scoping semantics, nothing needed to call it 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 baseline is 3. The description goes beyond the schema by explaining the semantic consequence of `world` — that 'server' vs 'client' separates an authoritative census from a replicated one — which is meaning the schema wording alone does not convey.

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 and resource ('Enumerate live instances of a class currently in memory') and explicitly distinguishes itself from the sibling get_actors_by_class by scope ('actors only' vs 'any UObject-derived type'). An agent can tell the two apart without opening either schema.

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?

Gives clear context that this is the general-purpose option beyond actors and explains when to pass `world` (to avoid a PIE session mixing host and client worlds). It stops short of an explicit 'use this when X, use get_actors_by_class when Y' routing statement, so the selection condition is implied rather than dictated.

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