Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_smart_object_slot_entrance_annotation

Add an entrance (entry/exit point) annotation to a smart object slot, including navigation and trajectory fields, to define how agents enter or exit the slot.

Instructions

Add an entrance (entry/exit point) annotation to a slot of a USmartObjectDefinition, including its navigation/trajectory fields.

Returns: { definition_path: string, slot_index: int, entrance_count: int, data_count: int, saved: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional gameplay tag names identifying the entrance
offsetNoOptional [x, y, z] local-space offset of the entrance
is_exitNoOptional: entrance can be used to exit the slot (default true)
is_entryNoOptional: entrance can be used to enter the slot (default true)
rotationNoPREFERRED: the OBJECT {"roll":R,"pitch":P,"yaw":Y} (any subset, absent axes are 0). The ARRAY form below is [pitch, yaw, roll] -- its index 2 is ROLL, NOT yaw, which once put a PlayerStart on its side. Optional [pitch, yaw, roll] local-space rotation (degrees)
slot_indexNoIndex of the slot to add the entrance to
definition_pathYesPath to the USmartObjectDefinition asset
selection_priorityNoOptional entrance selection priority: Lowest|Lower|Low|BelowNormal|Normal|AboveNormal|High|Higher|Highest (default Normal).
trace_ground_locationNoOptional: adjust ground location with a line trace (default true).
transition_check_radiusNoOptional radius of the transition trajectory check (default 10).
check_transition_trajectoryNoOptional: check collisions on the transition from nav location to slot (default false).
trajectory_slot_height_offsetNoOptional height offset at the slot for the transition check (default 40).
trajectory_start_height_offsetNoOptional height offset at the start of the transition check (default 80).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description goes beyond that by noting the response includes a `saved` flag, signaling the write is persisted to the asset, and reporting the resulting entrance/data counts -- useful post-state context not present in the annotations.

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?

Two sentences, purpose stated first, followed by the return shape. No padding, and the minimal structure is well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter mutation with no output schema, stating the return object is genuinely helpful. However, the description omits whether the definition asset is auto-saved, whether the slot must already exist, and any permission/state preconditions, leaving meaningful gaps for a write tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 13 parameters in detail (including the rotation array-order warning). The description only hints at 'navigation/trajectory fields', adding no syntax beyond what the schema supplies. Baseline 3 is appropriate.

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 (Add) plus resource (entrance annotation to a slot of a USmartObjectDefinition) and clarifies the domain concept as an entry/exit point. This distinguishes it clearly from the sibling get_smart_object_slot_entrance_annotations and remove_smart_object_slot_entrance_annotation without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never states when to use this tool versus the sibling readers/removers, nor any prerequisite such as the slot already existing or the asset needing to be saved. Usage is only inferable from the verb 'Add' in the name.

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