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

Annotations already declare this a safe, idempotent read; the description adds the decisive behavioral fact the annotations cannot convey — that on the free endpoint the call returns the coded error UPGRADE_REQUIRED with token instructions rather than a result. That is exactly the context an agent needs to avoid a wasted call.

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?

Three short sentences, with the tier restriction front-loaded and the fallback last. Nothing is redundant and the gating information comes before the alternative routing.

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 annotations and an output schema already present, the description covers the one thing structured fields do not: the upgrade-error behavior and tier gating. The only gap is how tickers would be supplied given the empty argument schema.

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?

There are no parameters, so the baseline is 4, but the description implies a 'set of tickers' input while the schema accepts nothing. That mismatch leaves the agent unsure how tickers are conveyed, which deducts from an otherwise parameter-free tool.

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 artifact — the full return-versus-drawdown trade-off map (Pareto frontier) — over a set of tickers, and contrasts it with portfolio_compare. It is clear what the tool produces, though the reference to 'a set of tickers' conflicts with a zero-argument schema, leaving a small ambiguity.

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 states the gate explicitly (FULL TIER ONLY), gives the motivating use case ('when you want the whole trade-off map'), and names the concrete free alternative portfolio_compare with its exact scope. When-to-use and when-not-to-use are both covered.

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