Convert currency (Philippine peso rates)

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false; the description adds the genuinely useful context that rates come from open.er-api.com and are refreshed daily, which tells the agent the data is external and can be a day stale. It does not say what happens with an unrecognized currency code or whether the daily rate can change results between calls, which is why it is not a 5.

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 sentences with zero padding: the conversion scope and example come first, the data source and update cadence second. Every clause carries information an agent would otherwise have to guess.

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 four-parameter, single-operation tool with full schema coverage and annotations covering the safety profile, the description supplies enough to call it correctly, and response_format makes an output schema unnecessary. The only gap is failure behavior for invalid codes or provider outages, which is minor at this complexity.

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 every parameter including the amount bounds and response_format enum is already documented. The description only reinforces the currency-code convention via the "100 USD to PHP" example and adds nothing about the PHP default target beyond what the schema states; baseline 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?

The description names a specific verb (convert) and resource (currency amounts) plus the scope: rates are cross-rates based on the Philippine peso, e.g. "100 USD to PHP". It also names the rate provider, so an agent knows this is a live-rate conversion rather than a static table lookup, and none of the siblings (weather, holidays, scholarships, regions) overlap with it.

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 worked example ("100 USD to PHP") implies the usage context, but there is no explicit when-to-use or when-not-to-use statement. Because no sibling tool performs currency conversion, the routing risk is low, so this is adequate rather than strong.

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