find_land_vehicles

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the trailing 'Read-only' adds nothing. What does add value is the disclosure of matching semantics: only body components are counted (not controller internals), and wheeled boats or aircraft can match, so results carry false positives. That is genuine behavioral context beyond structured fields, though return shape and paging behavior are left to the output schema.

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 purpose is front-loaded in the first clause and every sentence carries signal: scope, counting rule, false-positive caveat, follow-up routing. It is dense and clause-stacked in places ('including unnamed experiments, with paging'), and the final 'Read-only.' is redundant with annotations, but nothing is wasted overall.

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?

With an output schema present, return values need no explanation, and the description covers everything else an agent needs: what corpus is scanned, what counts as a match, the false-positive caveat, paging, and the correct next tool. No ambiguity remains about how to call or interpret it.

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% with clear per-parameter text for kind, limit, offset, search, and source, so the schema carries the load and baseline 3 applies. The description only loosely maps to parameters — 'wheel or track layouts' gestures at kind, 'installed Workshop items' at source, and 'including unnamed experiments' hints that search may not reach unnamed vehicles — but it adds no format or edge-case detail beyond the schema.

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 — scanning the player's saved vehicles or installed Workshop items for wheel/track layouts as land-build references — and scopes it (unnamed experiments included, paged). It explicitly distinguishes itself from list_game_vehicles (names only) and names analyze_land_vehicle as the deeper follow-up, so an agent can place it in the sibling set without opening a schema.

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?

Gives the routing rule directly: use analyze_land_vehicle to follow up on a hit, and use list_game_vehicles if only names are needed. It also sets expectations about when a result is *not* conclusive — 'a hit says nothing about a vehicle's purpose or quality' — which prevents over-reading matches.

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