Skip to main content
Glama

Navigation Manage

navigation_manage

Bake 3D navigation meshes from mesh-only children and query 2D/3D paths on selected maps. Use bake and path_get operations.

Instructions

Bounded 3D mesh-only navigation baking and 2D/3D path queries on an explicitly selected map.

Ops: • bake(path, scene_file="", force_sync=True) Bake a 3D region from bounded mesh-only children. Requires NavigationMesh root-children source mode and mesh-instance or both geometry settings. Supports unscripted Node / Node3D containers and MeshInstance3D using plain ArrayMesh, BoxMesh, PlaneMesh, SphereMesh, CylinderMesh or CapsuleMesh. Rejects other source nodes/settings (groups, colliders, CSG, GridMap, obstacles); custom source parser callbacks are never invoked. 2D baking is unsupported. Limits: 256 source nodes, 2048 triangles, 6144 vertices in total, 32 surfaces per ArrayMesh, and 1000000 estimated voxel cells. Source collection advances one bounded node per editor frame, then the engine bakes the collected snapshot asynchronously. These input limits are not a hardware-independent per-frame timing guarantee. Replies are deferred with a 30 s deadline; source edits abort the operation. Cancellation restores the old region resource; an already-started engine task may finish into its detached working copy. parse_ms reports collection time. force_sync=True pushes the result and synchronizes the map; False leaves map synchronization to the engine. Undo/redo restore exact retained resources. Only one bake per region; call directly, not in batch_execute. Resource form: none - per-region write. • path_get(from_point, to_point, dimension="3d", optimize=True, navigation_layers=1, region_path="", force_sync=False) Query a path between two world points ({x,y[,z]} or [x,y[,z]]). region_path selects the NavigationRegion3D/2D whose map to query; when omitted the edited scene root's world map is used — the op never guesses a scene's "first" region. Read-only: force_sync=False (default) never touches the map's shared async-iteration policy; force_sync=True opts in to the same toggle + map_force_update that bake uses when the query must see a just-baked region immediately. Returns points, point_count. Resource form: none — per-query read.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.2.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses asynchronous baking, the 30s deferred reply deadline, abort-on-source-edit behavior, cancellation restoring the old region resource, force_sync effects, undo/redo behavior, and the read-only nature of path_get with force_sync=False.

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?

The description is long but every sentence earns its place by adding a constraint, limit, or behavioral guarantee. The intro front-loads the tool's scope, the op bullets are scannable, and the canonical call shape is stated at the end without repetition.

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?

Given the tool's complexity and the presence of an output schema, the description is remarkably complete: it covers prerequisites, hard input limits, asynchronous execution, cancellation semantics, sync behavior, undo/redo, resource forms, and return values for path_get. The remaining parameter ambiguities are minor and do not undermine overall usability.

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 description coverage is 0%, so the inline op signatures are the only parameter documentation. They cover every parameter with defaults and explain several meaningfully, such as from_point formats, region_path selection, and force_sync side effects. However, a few parameters remain underspecified, notably bake's `path` target and the exact behavior of path_get's `optimize` and `navigation_layers`.

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?

The opening line names the exact domain: 'Bounded 3D mesh-only navigation baking and 2D/3D path queries.' It then enumerates two concrete ops with signatures—bake and path_get—so an agent can immediately understand the tool's scope and distinguish it from scene, mesh, or gridmap management siblings.

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?

The description gives explicit when-to-use and when-not-to-use guidance: bake requires NavigationMesh root-children source mode and mesh-instance/both geometry settings, rejects groups, colliders, CSG, GridMap, and obstacles, and explicitly says 2D baking is unsupported. It also states 'call directly, not in batch_execute' and explains how path_get selects a region versus the edited scene root's world map.

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