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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, and the description adds meaningful context beyond them: the data is a synthetic shared DEMO portfolio, output is capped at 6 dates, and defaults are environment-dependent. The benchmark paragraph explains the simulation semantics (same cash flows invested in the benchmark at that day's price, reopening at full value on a later start), which is genuine behavioral disclosure not present in structured fields.

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 front-loaded with the demo/read-only context and then moves in a clear order: returned series, then each parameter, then benchmark mechanics. Every sentence carries information, though the dense run-on phrasing of the parameter sentences makes it slower to scan than it could be.

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 and zero schema description coverage, the description is the only source of documentation, and it does explain the returned fields and their date-scoped meaning. The remaining gap is the shape of the response (how dates and lines are keyed together) and any error behavior for unresolvable line names.

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 0%, so the description must carry parameter meaning, and it largely does: date accepts YYYY-MM-DD or "today" as one value or a list, lines accepts "Portfolio Total", an account, type:/sector:/category:<name>, or "inflation", from accepts a date or "" for the first transaction, and benchmarks accepts keys or custom names. It stops short of restating the schema's enum keys and the maxItems bounds, and does not say how invalid line strings are handled.

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 the specific resource (the Portfolio value chart's plotted lines) and enumerates the exact series returned: value, valueDate, change, returnPct, ranking, highestBenchmark and a date cap of 6. An agent can tell it is a read of chart series rather than raw holdings or money flows, though it never explicitly contrasts itself with siblings such as holdings or money_flow.

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?

Usage is implied through defaults rather than stated as when-to-use guidance: omitted date means today, from may be "" for the first transaction, and in the in-app chat the arguments fall back to the on-screen chart. No alternatives or explicit exclusions are offered, so the agent must infer that non-chart data belongs to a sibling tool.

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