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

Annotations already declare readOnly/idempotent/closed-world, and the description still adds substantial context beyond them: nothing is changed, computation is free and model-free, a Last Price credential with routing read scope is required, and a sandbox key from self-registration is refused with 403 until a person claims the workspace. The 403 precondition in particular is a failure mode the agent could not infer from any structured field.

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?

Front-loaded with the payoff (what the findings say) and back-loaded with prerequisites; every clause carries information. The long semicolon-chained first sentence is dense and slightly run-on, costing a little readability, but no sentence is padding.

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?

No output schema exists, and the description compensates by naming the finding categories, their ordering, and the fact that each finding carries its numbers plus a suggested acting call. Auth, sandbox restriction, cost, and side-effect status are all covered, so an agent can decide, prepare, and interpret a call from the description alone.

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?

Zero parameters, so the baseline is 4 and there is no parameter semantics to add. The description correctly implies a no-argument call rather than leaving the agent hunting for optional filters.

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 resource (your workspace's own pricing records) and a specific output form (findings, most urgent first), then enumerates the finding types: learned estimates ready, unusable estimates with what each needs, quote-outcome coverage, guardrail holds, and expiring approvals. That enumeration distinguishes it clearly from point-read siblings like get_learned_pricing, get_price_guardrails, and list_approvals, which each return one slice of the same evidence.

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?

Sets clear context: this is a read-only aggregated review of what your records say, and each finding names the call that would act on it, which gives the agent an explicit handoff path to sibling mutation tools. It never states when NOT to use it (e.g., for a single estimate, use get_learned_pricing), so it falls short of the exclusion-plus-alternative bar.

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