check_passages

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and a closed world, so safety is covered. The description adds real behavioral value beyond that: width is measured as free width including agent radius, accuracy is 'about one cell', and the error 'errs on the small side' — a conservative bias an agent must know when interpreting pass/fail. It also discloses the return shape ('violations with positions and a map').

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?

The core purpose is front-loaded in the first sentence, and the following sentences each add a distinct fact (classification rule, measurement semantics, accuracy, return shape, level selection). It is dense but nearly every clause earns its place; the run-on middle sentence is the only mild structural wrinkle.

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 read-only analysis tool with no output schema, the description covers what an agent needs to call and interpret it: the measurement definition, the conservative error direction, and the returned artifacts. Minor gaps remain around 'names' and 'agent_height' and around cost/scale on large levels, but nothing essential for correct invocation is missing.

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 0% across 8 parameters, so the description must carry the load, and it does substantially: it defines min_door, min_corridor, door_length, the role of start, and implies agent_radius ('including the agent radius') and cell ('accurate to about one cell'). Only 'names' and 'agent_height' are left undefined, so it compensates well but not completely.

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 and resource — 'Find doorways and corridors of a level that are too narrow' — and defines the check precisely (narrow runs along the walkable centre line, doorway vs corridor classification). It is clearly distinguishable from siblings like walkable_map, route, and line_of_sight, which deal with reachability rather than narrowness.

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?

Usage is implied rather than stated: the tool is evidently a navigation-clearance validator, but the description never says when to prefer it over walkable_map, check_game_ready, or measure, nor does it state prerequisites such as needing geometry already built. The mention that 'start' picks the area 'when there are several levels' is the only contextual trigger offered.

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