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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the tool self-loads its data (no prerequisite fetch call needed) and how bar/groupBy interact to change what each datum represents (a period's closing balance). No rate limits, pagination, or auth details, but the added self-loading fact is meaningful.

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?

Two sentences, front-loaded with what the card shows before moving to the comparison configuration. The second sentence is long and dense with parenthetical examples, but every clause carries usable information and nothing is redundant.

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, the description does the work of describing the return payload (total, period change, chart, underlying balances), which is what an agent needs to know before calling. The gaps — startDate/endDate semantics and any differentiation from get_net_worth — are minor.

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 71%, so the schema carries most param documentation (period, note, groupBy, chartStyle all described inline). The description adds a combination rule the schema cannot express on its own: chartStyle:'bar' must be paired with groupBy, and each bar then represents that period's closing balance. It leaves startDate/endDate entirely unexplained beyond the period note that they override the window.

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 (render) and resource (net worth trend) and enumerates the card contents: current total, change over period, trend chart, account balances. It also notes 'It loads its own data,' which hints at why it exists separately from the raw get_net_worth sibling, but it never names that sibling or trend_card explicitly.

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 configuration guidance for the comparison use case ('pass chartStyle:bar plus groupBy — year for this-year-vs-last-year, month for month-by-month') and implies the default line/auto case is a plain trend. However, it never says when to choose this tool over the sibling get_net_worth or trace_card, so usage guidance is implied rather than explicit.

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