ecb_convert_invoices

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

With no annotations, the description carries the full behavioral burden. It usefully discloses official ECB EUR reference rates and prior-business-day fallback, but it does not clarify side effects, unsupported-currency behavior, output shape, or other operational constraints.

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?

The description is a single front-loaded sentence with no wasted language. It immediately communicates the core action, rate source, and fallback behavior.

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?

There are no annotations and no output schema, while the input schema has nested fields and batch constraints. The description gives the core purpose and fallback rule but is not complete enough about input fields, limits, or return values for an agent to call it confidently.

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 0%, and the single top-level parameter contains a nested invoice object with several fields. The description only vaguely references invoice amounts and currencies, leaving date, invoiceId, toCurrency default, and batch limits undocumented.

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 states a specific verb and resource: convert B2B invoice amounts across currencies. It also names the rate source and fallback behavior, making it clearly distinguishable from a generic FX-rate retrieval sibling such as ecb_fx_rates.

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 implies the tool is for B2B invoice currency conversion, which gives some usage context. However, it does not explicitly say when to use this versus ecb_fx_rates, nor does it state any exclusions or preconditions.

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