Skip to main content
Glama

get_properties

Read-onlyIdempotent

Batch-read several named properties from one object in a single call, returning typed values and a not_found list. Use to avoid multiple calls and verify replication.

Instructions

Batch-read several named properties off ONE object instance in a single call, returning a { name: typed_value } map plus a not_found[] list of the names that do not exist on that class (unlike get_actor_properties_by_class, a misspelling is REPORTED, not silently dropped). Use it instead of N calls to get_property_value; use list_object_properties when you do not know the names yet. Accepts world, so the SAME batch can be read on the server and on the client — the cheapest way to prove a value replicated — and the response stamps which world answered.

Returns: { object_path: string, class_name: string, values: object (typed: bool/number/string natively, struct/map as object, array/set as array, object-ref as path string), not_found: [string], world: string, 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: 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' reads 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 instance. 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).
property_namesYesNames of the properties to read; every name that the class does not declare comes back in not_found[]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already carry readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds real behavioral context beyond that: misspelled names are REPORTED via not_found[] (vs the sibling silently dropping them), an unrecognized world value errors rather than silently falling back, and the world selection determines which live instance answers. It does not detail rate limits or ordering guarantees, keeping it short of a 5.

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?

Front-loaded with the core action and return shape, then two scope/alternative sentences, then the world rationale — every sentence earns its place with no 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, yet the description fully enumerates the return structure including the typed value convention (bool/number/string native, struct/map as object, etc.) and the world_* / net_mode / pie_instance stamp fields. Combined with annotations and full schema coverage, 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 already 100%, so the baseline is 3; the description still adds value by explaining that `world` lets the same batch be read on server and client to prove replication, and that the response stamps which world answered. That semantic framing goes beyond the schema's operational description of the parameter values.

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 ('Batch-read several named properties off ONE object instance in a single call') and explicitly distinguishes itself from siblings get_actor_properties_by_class and get_property_value. The 'ONE object instance' constraint removes ambiguity about whether it spans multiple objects.

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?

Explicit when-to-use clauses: 'Use it instead of N calls to get_property_value' and 'use list_object_properties when you do not know the names yet'. Also names sibling get_actor_properties_by_class and the behavioral difference (reported vs silently dropped).

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