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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety and side-effect profile is fully covered and the barrage for extra behavioral detail is low. The description adds the return shape ('get all three back') and the no-comma formatting convention for American odds, but says nothing about invalid inputs or rounding behavior.

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?

Three tight sentences: purpose first, then the I/O contract with the formatting caveat, then example phrasings. Front-loaded and free of filler, though the example queries partially duplicate what the schema already illustrates.

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, the return values need not be spelled out, and annotations cover the safety profile; the description supplies the conversion set and input convention. It is essentially complete for a pure-function tool, with only edge-case behavior (invalid percentages, odds of 0) unaddressed.

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%, so both parameters are already documented in the schema, including accepted string forms ('+150', '62%', '2.5') and the enumerated format values. The description only restates 'give one value and its format' and adds the no-comma note, so baseline 3 is appropriate.

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 ('Convert between implied probability, American odds, and decimal odds') and defines the exact I/O contract: one value plus its format in, all three representations out. This is clearly distinguishable from siblings like calculate_ev and kelly_size, which consume odds rather than translate them.

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 concrete usage triggers via example phrasings ('what is +150 as a probability', 'convert 62% to American odds'), which tell the agent exactly which requests route here. It does not name exclusions or sibling alternatives (e.g. when to prefer calculate_ev or kelly_size), so it stops short of full routing guidance.

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