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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral fact beyond them: 'It loads its own data,' telling the agent no prerequisite data call is needed. It stops short of describing pagination or rendering constraints.

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, tightly front-loaded: what it renders, then the comparison recipe. The opening 'Render net_worth_trend:' slightly restates the tool name, a minor redundancy, but nothing else is wasted.

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?

For a 7-parameter, no-required-args card tool with no output schema, the description covers the output content, the comparison workflow, and the self-loading behavior. The detailed note/nextSteps guidance lives in the schema, which is acceptable; the description is complete enough to call correctly.

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 structured fields carry much of the load (period, groupBy, note, chartStyle all have descriptions). The description nonetheless adds value by explaining the chartStyle+groupBy interaction — that each bar is that period's closing balance — which neither schema field states alone.

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 names a specific verb (render) and resource (net worth trend) and enumerates what the card shows: current total, change over the period, a trend chart, and account balances. It distinguishes this card-rendering tool from data tools only implicitly, but the output content is concrete enough for an agent to select it.

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?

It gives one clear usage rule — pass chartStyle:'bar' plus groupBy to compare periods — with examples ('year' for this-year-vs-last-year). However it never says when to prefer this over siblings like get_net_worth or trend_card, so the routing guidance is incomplete.

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