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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds valuable behavioral details: the 50-row cap, that responses name the evaluated scope (document count + date range), and that each row includes its content_hash for citation. These go beyond annotations and inform the agent about limits and outputs, fully supporting transparency.

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 well-structured and front-loaded: it defines the key resource, states the action and cap, then default behavior, response details, and finally a redirect for credits. Every sentence conveys unique, necessary information without redundancy. It is concise given the tool's 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?

While the description covers scope, cap, and response details, it fails to mention the 'filter' parameter, which is a core capability for narrowing by category, amount, direction, etc. It also omits sorting. Given an output schema exists, return values are defined, but parameter usage is incomplete. A knowledgeable agent would need to open the schema to understand all filtering options, making this a partial gap.

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 adds meaning for 'scope' by explaining it narrows to accounts/products and a date range, and hints at 'limit' via the 50-row cap. However, it entirely omits the 'filter' parameter (text, category, amount, etc.) and 'order'/'sort_by', leaving those to the schema alone. Partial compensation for a low-coverage schema merits a 3.

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 states exactly what the tool does: 'Return a filtered list of transactions across your converted statements, capped at 50 rows.' It also defines the resource precisely ('a single line as printed on one account's statement') and implicitly distinguishes from list_transfers by focusing on transactions across converted statements. The explicit note about get_credits clarifies it is not a transaction, aiding differentiation.

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?

The description gives clear usage context: it explains default scope and how to narrow it via 'scope', and explicitly directs quota/credit questions to get_credits. However, it does not mention alternatives like list_transfers or aggregate, so guidance is partial. Still, the get_credits exclusion is a strong when-not signal, earning a 4.

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