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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context, and it does: it discloses a cost of 1 credit and explains that words output suits cheques and contracts. It does not describe the return value, and it mentions 'compact form' even though the input schema has no compact parameter, leaving an agent unsure how to request that mode.

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?

A single front-loaded sentence: the core operation comes first, supported variants follow, and the credit cost is appended in parentheses where it does not obstruct scanning. No redundant or filler wording.

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?

For a simple, read-only, four-parameter formatting utility with full schema coverage and annotations carrying the safety profile, this is nearly sufficient: purpose, variants, a use case, and cost are all present. The remaining gaps are the unexplained 'compact form' capability and the absence of any hint about the returned string, which matters slightly since no output schema exists.

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%, so the baseline is 3, but the schema's own text is terse ('boolean', 'number, required') and the description adds real meaning by explaining that the words option produces spelled-out amounts for cheques and contracts. Currency and locale are only named, not elaborated, so it is a modest gain rather than full coverage.

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 ('Format an amount') plus the variants it supports: any currency, any locale, compact form, and optionally in words. An agent can distinguish it from calculate/convert_units/fx_rates because formatting is a different operation. It stops short of explicitly saying it does not perform currency conversion, which is the one nearby confusion a sibling like fx_rates invites.

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?

The parenthetical '(for cheques and contracts)' gives a concrete use case that implies when the words mode is appropriate, which is genuine guidance. There is no explicit statement of when to prefer this over alternatives such as convert_units or fx_rates, nor any prerequisites, so usage is implied rather than stated.

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