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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two genuine behavioral facts beyond the schema: results are ordered newest-first and unmatched/undone matches are included rather than filtered out. It says nothing about volume, pagination, or the fact that the result set is unfiltered across all statements and payments.

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?

One short sentence with no filler, and the most decision-relevant qualifier (undone ones included) lands at the end while scope is front-loaded. The elliptical, verb-less phrasing is compact but costs a little immediate clarity about what action is being performed.

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 and no parameters, the description carries the burden of telling the agent what it gets back and what to do with it. It correctly states ordering and inclusion of undone matches, but does not say whether match identifiers suitable for rec_get_match or rec_unmatch are returned, leaving a real gap for a zero-parameter listing tool.

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 the schema provides no parameter semantics to supplement and the baseline of 4 applies. The description's scoping language ('every match', 'newest first', 'undone included') correctly implies there is no filtering capability the agent might look for.

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 sentence names the resource (matches between statement rows and recorded payments) and quantifies scope with 'every', which implicitly distinguishes it from the single-record sibling rec_get_match. However, the verb is elided in the noun-phrase construction, so the agent must infer that this is a list/read operation rather than a creation or lookup of one item.

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?

There is no explicit when-to-use guidance and no sibling is named as an alternative, despite close neighbors like rec_get_match, rec_candidates, rec_unmatch and rec_reconciliation. 'Undone ones included' faintly hints at auditing unmatched/reversed states, but the agent gets no rule for choosing this tool over rec_candidates or rec_reconciliation.

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