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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, covering the safety profile. The description adds the conceptual scoping of what an 'option' represents (a proposed local mobility choice) but does not state that this is a non-idempotent write (duplicates on repeat) or what happens to existing options. With annotations carrying the mutation/safety profile, a 3 is appropriate.

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 sentences, zero filler. The core purpose is front-loaded and the disambiguation from add_transport_option is stated in the same breath.

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?

Given a fully documented schema and annotations that cover the mutation profile, the description supplies the conceptual scoping and sibling disambiguation an agent needs to route correctly. It does not address idempotency/duplicate behavior, a minor gap for a non-idempotent write.

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 coverage is 100% and the nested data object is fully documented, including the type enum and notes field. The description adds semantic context for what the option means but no detail on parameters beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 action (propose how the traveller moves around locally) with the resource (getting-around option) and cites concrete examples (walking, public transport, rental car, bike, ride share). It explicitly distinguishes itself from the sibling add_transport_option by scoping to local mobility vs journey between destinations.

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 explicit when-to-use (local mobility budgets once at a destination) and when to use an alternative ('the journey between destinations belongs in add_transport_option'). The boundary condition and the named alternative are both stated directly.

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