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 adds real behavioral context beyond them: how the series is computed (replaying position snapshots and transactions), the currency semantics (home currency, surfaced as `currency`), and the default downsampling to 60 points.

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 dense sentences front-load the return content before the computation detail and defaults. No filler; every clause (series contents, computation method, currency, default window/downsampling) carries information.

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?

There is no output schema, so the description carries the burden of describing the return shape, and it does so fully (dated series with four named series and a currency field) while also covering defaults and computation. All three optional params are documented in the schema, leaving nothing an agent needs missing.

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 100%, so `from`, `to`, and `max_points` are already fully documented. The description largely restates the schema defaults and only adds the cumulative-includes-earlier-activity nuance (already in the schema) and the output currency, so it does not meaningfully extend parameter meaning.

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 resource (portfolio value over time for the authenticated user) and enumerates exactly what the series contains: total value, cumulative invested, cumulative realized, and MOIC. The temporal 'over time / dated series' framing cleanly separates it from the point-in-time get_portfolio sibling.

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 rather than stated: the agent can infer this is for historical trends versus a current snapshot, and it notes the default behavior (full history downsampled to 60 points). There is no explicit when-to-use-vs-alternatives guidance or exclusion such as naming get_portfolio for current values.

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