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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the description's job is added context — and it delivers: detection methodology (group by payee, regular intervals, consistent amounts), frequency classification, and the shape of the result (estimated annual cost per item plus totals). It omits caveats that matter for a heuristic detector, such as minimum occurrence thresholds or how irregular data produces false positives or misses.

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?

Purpose is front-loaded in the first sentence and each subsequent sentence adds distinct information: mechanism, return content, use cases, and the navigation warning. It runs long for two optional parameters, but no sentence is filler.

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?

A read-only, zero-required-parameter analytics tool with no output schema; the description compensates by describing what is returned (per-item annual cost and totals) and by pre-empting the agent's instinct to link to a report page. Nothing needed to invoke or interpret it is missing.

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%: both parameters carry descriptions including the default (6 months) and max (12), plus the auto-resolution behavior for user_id. The description adds nothing about window selection or when a longer lookback helps, so the schema does all the work — baseline 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?

States a specific verb and resource — 'Detects recurring expenses (subscriptions, memberships, regular bills) by analyzing transaction history' — and immediately explains the mechanism (payee grouping, interval/amount consistency, frequency classification). An agent can distinguish this from list_transactions or spending_comparison without opening any schema.

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?

Gives concrete use cases (subscription audits, forgotten charges, 'am I paying too much for X' comparisons) and an explicit routing instruction: answer from this data rather than offering a navigation link, because no report page maps to subscriptions. That is a named alternative behavior plus the condition that selects it, which is the top of the scale.

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