Summarize spending

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

readOnlyHint=true is provided, so the safety profile is covered by annotations. The description adds useful behavioral context: transfers excluded, spending positive/income negative, sorted descending. However, it doesn't discuss pagination, date range semantics, or what happens with empty results. Given annotations exist, a 3 is reasonable for the added context.

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?

Three short sentences, all information-dense with zero filler. Covers aggregation, exclusions, sign conventions, and sort order in ~20 words. Exceptionally efficient.

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?

No output schema exists, so the description should carry more weight for return format. It describes sign conventions and sort order (useful return semantics) but not the response structure, 'others' bucket behavior relation to top_n, or date range interpretation. For a summary tool with no output schema and 5 params at 20% coverage, there are gaps, though the description covers sign and sorting which is meaningful.

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 only 20%, meaning most of the 5 parameters lack schema descriptions (top_n, include_income, group_by enum values may exist in schema but not described in detail). The description explains 'group_by' semantics implicitly (category/payee/month) and mentions income is negative, which relates to include_income. But top_n and include_income behavior aren't explained in the description to compensate for the low schema coverage.

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?

Description states it aggregates spending by category, payee, or month. Clearly a read/summary tool. Distinguishes from siblings like get_transactions (list) and get_net_worth (balance) via the aggregation language. Not quite a 5 because it doesn't explicitly name what it contrasts with, but purpose is specific and clear.

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 mentions grouping dimensions and the exclusion of transfers, which gives some usage context. However, it doesn't explicitly state when to use this vs get_budget_month, get_transactions, or get_budget_averages. The implied context (aggregate spending summaries) is present but there's no explicit when/when-not guidance with alternatives.

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