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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully goes beyond that by specifying units (integer minor units, 45000 = 450.00) and date/time-zone semantics, which is genuine added value. However it says nothing about return shape, grouping cardinality, or whether ranges are inclusive, so it only partially carries the load left by the missing output schema.

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?

It is compact at three clauses, but poorly front-loaded: the opening fragment 'A year by budget month and category: expenses and income' has no verb and reads as a noun phrase, so the reader must reconstruct what the tool actually does. The unit and date notes are dense but earn their place.

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 one optional parameter and no output schema, an agent most needs to know what comes back; the description only hints at 'by budget month and category' and gives no structure, pagination, or empty-result behavior. The unit and time-zone conventions are valuable, but the picture is still incomplete.

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 0% for the single 'year' parameter, so the description must compensate. It clarifies 'YYYY' formatting and the meaning of a budget period (YYYY-MM, the period starting in that month), which adds real semantics, but it never says whether the year is optional, whether it defaults to the current year, or how calendar vs. budget-year boundaries are treated.

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 gestures at an aggregation of expenses and income by budget month and category for a year, but it never states a verb or the retrieval action ('returns yearly expense/income totals grouped by budget month and category'). It also does not distinguish this from close siblings like get_overview, get_budget, or get_retrospective, so an agent must guess which aggregate report to pick.

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 when-to-use guidance, no mention of prerequisites, and no named alternative tool. With siblings get_overview, get_budget, get_retrospective, get_balances all returning summaries, the absence of routing guidance is a real gap.

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