xpayr_list_payment_sessions

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

No annotations are supplied, so the description carries the full behavioral burden. It does not state that the operation is read-only, does not explain pagination mechanics (cursor vs offset, how to fetch the next page), gives no ordering/default-sort behavior, and says nothing about authorization scope or result shape for a tool that returns merchant payment data.

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?

A single front-loaded sentence with no filler, and the resource is stated before the modifiers. It is efficient, though the trailing filter enumeration largely duplicates the schema rather than using the space for behavioral detail.

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 four-parameter, all-optional read tool with full schema coverage and no output schema, the description covers what the tool returns at a high level. It is nevertheless thin on the things an agent must know to call it well: pagination progression, default ordering, and confirmation that no state is mutated.

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 the four parameters are already fully documented and the baseline is 3. The description restates the same filter dimensions and adds no format or semantics beyond the schema; it also lists only four status values (pending, completed, expired, failed) while the schema includes 'processing', a small inconsistency that adds no clarifying value.

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 names a specific verb (List) and resource (merchant crypto payment sessions) and enumerates the filter dimensions, which cleanly separates it from sibling tools dealing with agents, intents, or single-session retrieval. It stops short of explicitly contrasting itself with the closest list-style sibling, so it is clear but not maximally differentiated.

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 is only implied: the word 'List' plus the optional filters suggests this is the browse/enumerate entry point, and the sibling names imply get_payment_session is for single lookups. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative for retrieving one specific session.

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