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

Annotations already declare readOnly, openWorld, and idempotent hints, so the safety profile is covered. The description adds rich behavioral detail: pagination via next_offset, the caveat that omitted routes on a page are not necessarily unsupported, optional delivery fields, and a clear warning not to hard-code minima or assume deliverability. This goes well beyond the structured annotations.

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 dense but every sentence carries useful information. It front-loads the core purpose and direction mapping, then adds pagination and safety cautions. No redundancy; though slightly long, it is efficient given the complexity.

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 read-only listing tool with no output schema, the description covers the essential operational details: direction meanings, pagination mechanics, optional fields, and a critical caveat about hard-coding values. It could benefit from explicitly stating that offset/limit parameters control pagination, but overall it is complete enough for an agent to call the tool correctly.

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%, so the description must compensate. It explains direction values fully and mentions filtering by asset/network, but does not explain limit or offset beyond implying pagination. The offset semantics are only hinted via next_offset, and limit is never addressed. This is a partial compensation, not complete.

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 clearly states the tool lists a public catalog of settlement options, and distinguishes two directions (deposit vs delivery) with explicit endpoint mapping. It is not a tautology and stands apart from siblings like network health or payer limit checks.

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?

It gives usage context by explaining the two direction values and their meanings, and advises on pagination and live preview. However, it does not explicitly compare against alternative tools or state when not to use it, leaving the agent to infer the selection criteria from the description alone.

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