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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety and repeatability are covered. The description adds that this is a UI-side status probe, which is useful context beyond the annotations. It does not say whether status is eventually consistent, how often it refreshes, or what states 'rendered' can take, which matters for a polling-style status check.

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 short sentences, front-loaded with the return semantics and followed by the calling constraint; nothing is wasted. The size is appropriate, though the second sentence's 'never by the model' phrasing borders on instructional rather than descriptive.

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, the description carries the burden of explaining the response, and it does so only at a high level ('rendered yet' plus 'run's status') without enumerating possible status values. The parameter's provenance is also missing, which is the main gap for a one-parameter lookup tool.

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% and there is a single required parameter, quoteId, whose origin and format the description never explains — the agent must guess it comes from estimate_run_cost. A description of this kind should say where quoteId is obtained and what happens if it's unknown or expired.

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 (an estimate_run_cost quote) and states exactly what it reports: whether the quote has been rendered and the run's status. It connects to the sibling estimate_run_cost, so an agent can place it in the workflow. It stops short of a crisp verb like 'read/report,' framing the purpose as a question, which softens it slightly.

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 gives an explicit exclusion — 'Called by the cost check panel, never by the model' — which tells the agent when not to call it and why. It doesn't describe the alternative the agent should use instead (presumably estimate_run_cost itself for fresh pricing), leaving that inference to the reader.

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