Find game objects by name, kind, GUID, or id and retrieve live positions and rotations. Use pagination and optional full details to inspect specific objects or browse connected tables.
Find objects by name, kind, GUID or id, including live positions and rotations. Paginated. details includes full properties.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| details | No | ||
| table_id | No | Omit to use the active connected table. |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real value beyond that: results include live positions and rotations, results are paginated, and the details flag expands to full properties (implying a heavier payload). It omits the default limit of 100/max 500 and any ordering guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short fragments, front-loaded with the core search capability, with zero filler. The telegraphic style slightly hurts readability but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter listing tool with no output schema and thin schema coverage, the description covers return contents and pagination but not result ordering, what happens with an empty query, or how table_id defaulting interacts with results. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (table_id alone is documented), so the description must compensate. It does explain query's accepted key types (name, kind, GUID, id) and details' effect, and 'Paginated' implies limit/offset, but defaults, maximums, and empty-query behavior are left unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find) and resource (objects), plus the searchable keys: name, kind, GUID, id. It is clearly distinguishable from object_read and objects_spawn by implication, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance, and never points to object_read for a single-object fetch or explains how this differs from objects_list versus asset/library lookups. 'Paginated' hints at bulk listing but leaves selection criteria to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.