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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context beyond that — it does, by scoping freshness to the latest validated ledger and by stating that a congestion score accompanies the fee tiers. It stops short of describing freshness/rate-limit behavior or the number of tiers, so it is not fully exhaustive.

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?

Front-loaded with what it returns, then when-to-use, then exclusions, then a literal call example. Every clause earns its place with no restatement of the title or name.

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?

An output schema exists and the description does not need to enumerate return values, yet it still characterizes the payload (fee tiers in drops plus congestion score). For a zero-parameter, read-only lookup, nothing an agent needs to call it correctly 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The schema is an empty object and the description correctly shows the invocation as 'get_fee {}'.

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 ('Current XRPL fee tiers in drops') plus the derived value ('congestion score'), which is exactly the kind of specific output framing an agent needs. It also separates itself from siblings by declaring it is 'not a price feed and not a historical series' and describes 'the latest validated ledger only'.

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?

Gives explicit when-to-use ('Before submitting a transaction, to choose a `Fee` and to decide whether the network is congested') and explicit when-not ('Not a price feed and not a historical series'). The alternative framing is clear even without naming a specific sibling.

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