Skip to main content
Glama

get_object_info

Read-onlyIdempotent

Inspect an unfamiliar Unreal object to discover its identity, class, reflected property names, typed values, and components before editing it with set_properties.

Instructions

Portrait of one object whose property names you do not know yet: its identity and class, class flags and interfaces, every reflected property as { name: typed_value }, and for an actor its components.

Use it first on anything unfamiliar, then write with set_properties using the names it lists. Once you know the names, get_properties reads only those and is far cheaper: an actor's portrait can run to hundreds of properties. get_class_properties describes a class with no instance, and get_actor_components lists the components alone.

object_path takes a path from find_assets_by_name, an object_path from get_graph_nodes or another reader, or an actor's component as "Actor.Component", the actor by its internal name. {"object_path": "/Game/Blueprints/BP_Door", "include_properties": false} answers only "what is this?", with identity and class. include_property_metadata=true adds each property's type, editability, replication and clamp range next to its value, which says whether set_properties can write it. world "server", "client" or "pie:N" portrays the live instance in Play-in-Editor, and the reply names the world that answered.

A reply over 40,000 characters (the console variable mcp.OversizeResponseChars), common for a Blueprint with include_property_metadata, is written to a file instead: the reply keeps its scalar fields and gives report_path, which get_mcp_audit_report reads. An object or a world it cannot find is an error naming what it searched.

Returns: { object_path: string, object_name: string, class_name: string, class_path: string, super_class: string, is_valid: bool, is_abstract, is_deprecated, is_placeable, is_native, config_name, implemented_interfaces: [{interface, implemented_by_k2}], class_group?, is_blueprintable?, is_blueprint_type?, display_name?, tooltip?, properties?: {prop_name: typed_value} | [<typed descriptor + value>], property_count?: int, components?: [{name, class}], world: string, world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number } -- properties/property_count/components only with include_properties; properties is the array form with include_property_metadata; super_class is "None" for UObject.

Input Schema

NameRequiredDescriptionDefault
worldNoOptional world selector: absent/'editor' (default: the editor/asset instance) | 'pie' (ambiguous: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'game' (alias of 'pie'). Anything other than absent/'editor' portrays the LIVE instance in that world; an UNRECOGNIZED value is an error naming the worlds that exist, never a silent fallback to another world.
object_pathYesPath or name of the object to inspect. In the editor world: full object path, asset path, CDO/archetype, an asset's sub-object as the readers give its object_path -- a graph node from get_graph_nodes, a sound cue node, a Niagara renderer or simulation stage, a PCG node's settings_path, a behavior tree node, a camera rig node, a Mass trait, a physics body -- also written "/Game/Asset:SubObject", or a dotted "Actor[.Component[.Subobject]]" whose first segment is the actor's INTERNAL name. In a live world: a fully-qualified PIE path or the same dotted form (first segment matches internal name OR editor label).
include_propertiesNoOptional bool (default true). false skips the properties and the components list, leaving identity and class only.
include_property_metadataNoOptional bool (default false). true returns properties as an ARRAY of typed descriptors (see get_class_properties) each with its current `value`, instead of the { name: typed_value } map.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • changedInput schema / properties / object_path / description
      Previous value: -"Path or name of the object to inspect. In the editor world: full object path, asset path, CDO/archetype, or a dotted \"Actor[.Component[.Subobject]]\" whose first segment is the actor's INTERNAL name. In a live world: a fully-qualified PIE path or the same dotted form (first segment matches internal name OR editor label)."New value: +"Path or name of the object to inspect. In the editor world: full object path, asset path, CDO/archetype, an asset's sub-object as the readers give its object_path -- a graph node from get_graph_nodes, a sound cue node, a Niagara renderer or simulation stage, a PCG node's settings_path, a behavior tree node, a camera rig node, a Mass trait, a physics body -- also written \"/Game/Asset:SubObject\", or a dotted \"Actor[.Component[.Subobject]]\" whose first segment is the actor's INTERNAL name. In a live world: a fully-qualified PIE path or the same dotted form (first segment matches internal name OR editor label)."
  2. Addedv2.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: responses over 40,000 chars spill to a file with report_path consumed by get_mcp_audit_report, missing objects/worlds produce an error naming what was searched, and the reply names which world answered. That is exactly the operational context annotations cannot express.

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 and routing before mechanics, and each paragraph covers a distinct concern (selection, path forms, oversize/error behavior, return shape). It is dense and long, with the enumerated Returns block doing necessary work in the absence of an output schema, but a few schema-echoing details could be trimmed.

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 enumerates the return fields and flags which are conditional (properties/property_count/components only with include_properties; array form with include_property_metadata; super_class is "None" for UObject). Combined with the error and oversize behavior, an agent has everything needed to call and interpret this tool.

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: object_path's accepted provenance (find_assets_by_name, get_graph_nodes readers, "Actor.Component" dotted form), and why include_property_metadata matters (type/editability/replication/clamp tell you whether set_properties can write it). Much of the world-selector detail is echoed from the schema rather than added.

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?

Opens with a concrete metaphor that resolves to a specific verb and resource: identity, class, class flags, interfaces, reflected properties, and components for actors. It explicitly positions itself against get_properties, get_class_properties, and get_actor_components, so an agent can discriminate it from siblings without opening a 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?

"Use it first on anything unfamiliar, then write with set_properties using the names it lists" gives an explicit ordering, and it names the condition that selects the cheaper alternative ("once you know the names, get_properties reads only those and is far cheaper"). It also routes away for class-only and components-only queries, and the include_properties=false form is framed as the "what is this?" case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.