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

Annotations already declare read-only, idempotent, non-destructive and open-world, and the description adds genuinely new context: the upstream source, that it is a single CelerAPI call, that the rate is a published ECB reference rather than a live quote, and the x402 USDC price. This is exactly the kind of cost, provenance and freshness disclosure annotations cannot carry, and nothing contradicts them.

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?

Roughly six short sentences, front-loaded with the action and its data source, then constraints, then return shape, then the important caveat and cost. Every sentence carries distinct information; nothing is padding.

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 three-parameter conversion tool it covers source, constraints, return fields, freshness caveat, billing and a call example. An output schema exists, yet the description still names the returned fields without over-explaining, so nothing an agent needs 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 coverage is 0%, so the description must carry the load, and it does: it names all three parameters, clarifies the amount must be finite and within bounds, and specifies supported three-letter ISO codes plus a worked example. Some of that (the 1e9 ceiling, the >0 floor, the three-letter pattern) duplicates what the JSON Schema already encodes, which keeps it from a 5.

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 ("Convert a specified amount") plus the data source (ECB reference rates via Frankfurter), which distinguishes it from rate-lookup siblings. An agent can tell immediately this returns a converted value rather than a bare rate.

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?

Explicitly rules out a common mistake by stating "get_fx_rate is not a prerequisite" and frames the use case as an "Informational estimate, not trade execution or a real-time quote." It stops short of saying when to prefer get_fx_rate or get_historical_fx_rate instead, so routing is implied rather than fully specified.

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