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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description then adds behavior annotations cannot express: the two-phase question/answer protocol, the shape of the return value, and how unanswered inputs are defaulted and flagged. This is meaningful context beyond the 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?

Four sentences, front-loaded with the purpose and output before the calling protocol. Every sentence carries distinct information (output shape, call sequence, defaults, disclaimer) with no restatement of the name or schema.

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 must explain the return value, and it does: a low-to-high USD range, the supporting arithmetic, and a `questions` payload with answer ids. Combined with the stated defaulting rule, an agent has everything needed to drive both calls 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?

With 100% schema coverage the schema already documents both parameters, and the `answers` schema even gives the {hours: 1000-10000} example. The description still adds real semantics: that `kind` alone is a valid first call, that answer values must be listed answer ids sent as text, and that omissions default. It does not add format detail for the returned questions themselves.

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 states a specific computation ('what published prices imply for a holding of data') and names the concrete output ('a low-to-high range in US dollars with the arithmetic behind it'). That distinguishes it from the sibling lookup tools (search_prices, get_market_rates) which find prices rather than value a holding.

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 prescribes an explicit two-step procedure: call first with only `kind` to get the questions and answer ids, ask the holder, then call again with `answers`. It also covers the non-happy path ('questions not answered are taken at their defaults and marked as assumed') and sets expectations with 'an indication, not an offer.'

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