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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered without the description. The description adds only the return shape ({FR, US, UK, EU}), which largely duplicates the output schema, and says nothing about conversion-table nuances (e.g., whether cup letters are re-mapped across systems) or failure behavior for odd band/cup inputs.

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 short sentences, purpose front-loaded, no padding. The return-shape fragment and the cross-reference are compact enough to earn their place.

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 defined and rich annotations, the description does not need to explain return values or safety, and it confirms the tool returns all four systems. It is slightly thin on when this converter should be chosen over related sizing tools, but nothing required to invoke it correctly 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 100% and all three parameters (band_size, cup, from_system) are documented in the schema, including the enum for from_system. The description's mention of the four systems restates the enum rather than adding meaning, so the baseline of 3 applies.

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?

Names a specific verb (Convert) and resource (bra size) and enumerates the four sizing systems it maps between, so the agent knows exactly what it produces. It does not, however, distinguish itself from the adjacent non-conversion sibling calculate_bra_size, leaving the agent to infer the difference from the name alone.

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 only implied by the topic: convert a size when you need it in another system. There is no explicit when-to-use versus alternatives statement and no exclusions, though the closing pointer to list_bundles gives a mild ecosystem hint about related calculators.

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