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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the required role, the underlying GET endpoint, and the constraint that at least one period must be supplied — a real behavioral rule that affects callability.

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?

Four short segments — what is returned, how to filter, the period precondition, and the auth/endpoint footer — with no filler and the most decision-relevant content early. The opening field enumeration runs long, but it substitutes for a missing output schema, so it earns its space.

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 10-parameter read tool with no output schema and no required parameters, the description covers the essentials: what comes back, how to narrow results, that a date window is mandatory, and what permission is needed. The one soft spot is the vagueness of 'Give at least one period' — it doesn't state whether one of the four date bounds suffices or whether a from/to pair is expected.

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 100%, so the baseline is 3, but the description adds real meaning: it groups the date parameters into transaction-date vs reservation-date families and makes explicit that a period is mandatory even though the schema lists zero required parameters. It doesn't clarify the edge case of passing conflicting flags like only_paid and only_unpaid together.

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 the resource (transactions: fees, membership fees, payments, refunds), the two date dimensions it can be scoped by, and enumerates the returned fields including member contact info. It's specific enough that an agent knows this is the transactions ledger rather than reservations or sales aggregates, though it never explicitly contrasts itself with siblings like sales_summary or list_reservations.

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 states positive usage conditions clearly: filter by type, paid/unpaid and payment type, and provide at least one period, plus the prerequisite 'Needs the Transactions role (Read).' The missing piece is exclusions — nothing says when to prefer sales_summary or membership_report over this tool, so an agent facing an aggregate question has to infer.

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