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

Annotations already cover the read-only, idempotent, closed-world safety profile, so the bar is lower, and the description adds real value on top: negatives and values up to 10^15 are handled, currency form yields grammatical agreement plus correct minor-unit name/count, and it discloses a billing mechanism ($0.05 per successful call via x402/USDC on Base) — an auth/payment constraint the agent cannot see elsewhere.

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 dense paragraph with no filler; capabilities are front-loaded (languages, forms) before constraints and pricing. Slightly long sentences but every clause carries information an agent needs.

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 stateless formatting tool with no output schema and full schema coverage, the description covers scope, limits, locale/form constraints and even cost. The only gap is that it never sketches the shape of the returned string, which is minor since no output schema is claimed.

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 description adds meaning beyond the schema by tying the currency parameter to grammatical agreement/minor-unit behavior and by revealing that ordinal form is only valid for en, nl, de and fr — a restriction absent from the enum definition itself.

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?

Starts with a precise verb+resource ('Spell a number out in words') and enumerates the 12 supported locales and the cardinal/currency/year/ordinal forms. It is immediately distinguishable from siblings like num_radix, num_allocate and num_stats, which operate on numbers but not natural-language rendering.

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 description gives strong context on applicable forms and constraints (currency form needs the ISO 4217 code; ordinal only exists for four languages) but never states when to pick this tool over a sibling or what to do when the language/form combination is unsupported. Usage is implied rather than routed.

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