Spawns an ANavLinkProxy actor in the editor world at a given location to define AI navigation links. Returns actor details including name, label, path, class, and success.
Spawns an ANavLinkProxy actor in the editor world at a location
Returns: { actor_name, actor_label, actor_path, actor_class, success }
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | [x, y, z] world location for the nav link proxy |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=false, destructive=false, so the safety profile is covered. The description adds only that the actor is placed in the editor world at a location. It does not say what happens if the location is invalid, whether the actor is selectable/undoable, or what 'success' means.
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?
Two short lines with the action front-loaded and the return contract listed compactly. No filler, though the return list is somewhat redundant given there is no output schema to reference.
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 single-param spawn in a dense sibling ecosystem, the description covers the core action and return shape, but omits editor-world prerequisites, invalid-location behavior, and any routing against nearby spawn_* nav tools. Adequate but leaves real 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 description coverage is 100% and the lone 'location' parameter is documented with format '[x, y, z]' in the schema. The description adds no format, default, or validity detail beyond that, so baseline 3 applies.
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 ('Spawns') and resource ('ANavLinkProxy actor') plus the world context ('in the editor world'), so the agent knows exactly what is created. It does not distinguish from the related sibling spawn_nav_modifier_volume, but the resource is named 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?
No when-to-use or when-not-to-use guidance. Nothing tells the agent this is an editor-authoring step distinct from runtime navigation tools like rebuild_navigation or spawn_nav_modifier_volume, so routing must be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.