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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results include 'the working shown', and units may be mixed freely, which affects how an agent interprets the output. No return format details, but the added context is meaningful.

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?

Front-loaded with a concrete example, followed by the input rule and unit flexibility. The trailing marketing URL is the only non-earning element, but everything else is tight.

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 no output schema, the description compensates by noting the answer and the working are shown. The 'any two of three' rule effectively explains the mode parameter. Remaining gaps (e.g. what rounding or output shape to expect) are minor for a simple calculator.

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 enums documented for mode, distUnit and speedUnit, so the schema carries the parameter burden. The description reinforces that distance and speed units can be mixed freely across km/miles and kmh/mph, adding modest value over the schema but no syntax or constraint detail.

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+resource: solve for the missing one of speed, distance or time from the other two, illustrated with a concrete worked example ('150 km in 2 h 30 min is 60 km/h'). This is clearly distinguishable from unit_converter or time_duration_calculator, though it does not explicitly disambiguate from the neighboring pace_calculator.

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?

'Give any two of speed, distance and time to get the third' tells the agent exactly what input combination is required, which is the key usage rule. There is no explicit when-not guidance or named alternative, but the operative condition for calling this tool is stated clearly.

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