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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful behavioral details: it returns a PNG image and also includes the figures as a table for exact quoting. It also states the currency handling rule (never summed across). These go beyond annotations and help the agent set expectations without contradiction.

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?

The description is two sentences, front-loads the core purpose, and every clause adds information: what it produces, the chart kinds, currency scoping, and the table output. No fluff or redundancy.

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?

Given the 7 parameters and an output schema, the description covers the main use cases and output format. It mentions the table return and the currency rule, which are key. It doesn't detail per-kind parameter usage, but the schema descriptions already do that. The output schema documents return values, so the description is sufficiently complete for an agent to decide when and how to call it.

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 86%, so most parameters are already described. The description adds a little extra meaning—'One panel per currency' explains the currency parameter behavior, and 'top categories' hints at the top parameter. However, it does not systematically explain parameter interplay (e.g., which kinds use from/to). With high schema coverage, baseline 3 is appropriate.

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 clearly states the tool's purpose: it produces a PNG chart of financial data, listing four specific chart kinds (spending by month, income vs spending, top categories, balance over time). It also clarifies scope (one panel per currency) and output (also a table). This distinguishes it from sibling text-based tools like spending_summary.

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 implies usage—when the user needs a visual chart—but does not explicitly name alternatives or provide when-not-to-use guidance. It says 'as a PNG you can show the user', which suggests user-facing scenarios, but it doesn't contrast with spending_summary, spending_trend, or net_worth. Usage context is inferable but not explicit.

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