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

Annotations already declare readOnlyHint=true and openWorldHint=false, so 'Read-only, free, no key' partly restates them. But the description adds genuinely non-structured behavior: drafts are never presented as law, each answer carries dated steps, the source document and the day it was read, and it explicitly disclaims legal advice. That provenance and draft-exclusion detail is real added value.

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 purpose is front-loaded and there is no filler, but the central clause ('each rule SwapEazi holds answers applies, depends (and on what) or does not apply, with its dated steps, its official document and the day it was read') is dense and hard to parse on one pass. 'Read-only, free, no key' duplicates the annotations and could be cut.

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?

With no output schema, the description does the work of explaining what comes back: per-rule status, dated steps, source document and read date. For a four-parameter read-only lookup that is nearly enough; it does not say what happens for an unknown corridor or currency, or whether results are exhaustive.

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 100%, so all four parameters (from, to, route, currency) are already documented, including the two-letter-country-or-currency formats and the route default of 'both when left out'. The description echoes those same facts ('two-letter countries, or currencies', 'bank or stablecoin') rather than adding format, precedence or validation rules, so 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 opening clause names a specific verb and resource — which payout rules reach a payout, and when — and scopes it to a corridor (countries or currencies) plus a route (bank or stablecoin). It also enumerates the three answer states (applies, depends, does not apply), which no sibling tool provides, so an agent can separate it from assess_route, check_constraints or route_intent.

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?

Usage context is clear: supply from/to as either countries or currencies, plus an optional route, and the tool answers rule applicability. It also implicitly routes the agent away from calling this redundantly by noting that route_intent already carries these rules in its rules field. It stops short of an explicit when-not statement or a named alternative for a different question (e.g. cost or timing).

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