Skip to main content
Glama

Navigation (pathfinding)

navigation

Set up pathfinding in Godot scenes: bake regions from child geometry, add agents and links, query paths, and inspect the map to verify a level is connected before running.

Instructions

Pathfinding setup: navigation regions (2D polygons / 3D navmeshes) baked from their child geometry, NavigationAgents with sane defaults and usage code, navigation links (jumps/teleports), an overview of the scene's navigation, and editor-side path queries to verify a level is connected.

Actions:

  • region: {type?: 2d|3d (default from parent), name?, parent?='.', outline?: [[x,y],...] | outlines?: [...] (several walkable areas, merged) | rect?: [x,y,w,h] (2D walkable area, pixels), holes?: [[[x,y],...]] (2D: unwalkable areas, added as NavigationObstacle2D children that carve the bake), sources?: [node paths] (extra geometry to bake from, e.g. a TileMapLayer whose tiles have collision, or level nodes that aren't children of the region; switches the region to group source mode), nav?: {agent_radius, cell_size, parsed_geometry_type: meshes|static_colliders|both, source_geometry_mode: root_node_children|groups_with_children|groups_explicit, collision_mask: names|numbers, agent_height, agent_max_climb, ...} (NavigationPolygon/NavigationMesh props; 2D and 3D names both accepted), bake?=true when an outline is given (2D) / always (3D), position?, props?} create a NavigationRegion2D/3D. Obstacles are the region's children (plus sources): 2D bakes carve child collision shapes/meshes out of the outline (agent_radius default 10px); 3D bakes walkable surfaces from child meshes/static bodies. Add children later (physics.body parent: region) then navigation.bake.

  • bake: {path: region, sources?: [node paths], nav?: {...bake settings, as in region}} (re)bake the region's navigation polygon/mesh from its source geometry (synchronous, undoable). Returns polygon/vertex counts and bounds.

  • agent: {parent: body node, type?: 2d|3d, name?, radius?, max_speed?, avoidance?: bool, path_desired_distance?, target_desired_distance?, props?} add a NavigationAgent2D/3D (defaults tuned: 4px / 0.5m path & target distances). Returns the movement code to use in the body's script.

  • link: {from: [x,y] | [x,y,z], to, parent?='.', name?, bidirectional?=true, props?: {enter_cost, travel_cost, navigation_layers}} add a NavigationLink2D/3D connecting two points (jump down a ledge, ladder, teleporter). Positions are in the parent's space.

  • path: {from: [x,y] | [x,y,z], to, type?: 2d|3d, navigation_layers?=1, tolerance?=8px/0.5m} query a path on the edited scene's navigation map: points, length, reachable. Use it to verify level connectivity before running the game.

  • info: {path?} one navigation node, or (no path) a scene overview: regions (polygons, bounds, agent radius, obstacle count), agents, links, obstacles, map cell sizes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd point [x, y] or [x, y, z].
navNoNavigationPolygon / NavigationMesh bake settings (agent_radius, cell_size, parsed_geometry_type: meshes|static_colliders|both, collision_mask, ...).
bakeNoBake right after creating the region.
fromNoStart point [x, y] or [x, y, z].
nameNoNode name.
pathNoNode path relative to the scene root ('.' = root, 'Player/Sprite2D', '%Unique'), or a res:// file path, depending on the action.
rectNo[x, y, width, height] walkable rectangle (2D).
typeNo2d or 3d.
holesNo[[[x, y], ...], ...] unwalkable polygons inside the outline (2D).
propsNoProperty map. Values are coerced to the property type: numbers, [x,y], 'Vector2(1,2)', '#ff8800', 'res://file', {"type":"RectangleShape2D","size":[32,32]} for new resources, enum names as strings.
sceneNores:// scene to operate on; opened in the editor if needed. Defaults to the currently edited scene.
actionYesWhat to do. See the tool description for each action's parameters.
heightNoAgent height (3D).
parentNoParent node path.
radiusNoAgent radius.
outlineNo[[x, y], ...] walkable outline (2D).
sourcesNoExtra node paths whose geometry/collision the bake uses (e.g. a TileMapLayer).
outlinesNoSeveral walkable outlines (2D), merged. Use holes for unwalkable areas.
positionNo[x, y] or [x, y, z].
avoidanceNoEnable agent avoidance (RVO).
max_speedNoAgent max speed.
toleranceNopath: max distance between path end and 'to' to count as reachable.
bidirectionalNoLink usable both ways.
navigation_layersNoNavigation layer bitmask for path queries.
path_desired_distanceNoAgent: distance to a path point to consider it reached.
target_desired_distanceNoAgent: distance to the target to consider it reached.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare it is not read-only, not destructive, and not open-world, so the description carries the real behavioral load and does so: bake is called out as synchronous and undoable, it returns polygon/vertex counts and bounds, agent returns the movement code to paste into the body's script, and holes are created as NavigationObstacle2D children that carve the bake. Missing only auth/permission notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line purpose followed by a tight bulleted action list, which is the right structure for a 26-parameter multi-action tool. The individual bullets are dense run-ons packed with parentheticals, costing some readability, but little is genuinely wasted.

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

Completeness4/5

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

For a high-complexity tool with 26 params, nested objects, and no output schema, the description covers every action, key defaults, and even partial return values (path points/length/reachable, bake counts/bounds, info overview). Only error behavior and scene-editor side effects are left unaddressed, which is minor.

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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: defaults (agent_radius 10px in 2D, 4px/0.5m path & target distances), that bake?=true is implied when an outline is given (2D) and always on in 3D, that outlines are merged and holes carve them, and that link positions are in the parent's space.

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?

Opens with a specific domain statement ('Pathfinding setup') and then enumerates six concrete actions (region, bake, agent, link, path, info), each with a verb+resource (create a NavigationRegion2D/3D, add a NavigationAgent, query a path). An agent can clearly separate this from siblings like physics, tiles, or node, which do not cover navmesh baking or path queries.

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

Usage Guidelines4/5

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

Usage context is embedded for each action: path is for 'verify level connectivity before running the game', bake is for re-baking after adding children, region switches to group source mode when sources are given. It never names an alternative tool to use instead, so it stops short of explicit when-not guidance.

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