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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description then adds genuinely useful behavioral context beyond them, since there is no output schema: it explains what each returned state means ('waiting (an answer is on its way)', 'answered (with the answer)') and covers the dispute re-drive states. It stops short of describing pagination or the overall response shape.

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?

The whole definition is a single semicolon-chained sentence that is compact but cryptic and not front-loaded with the operation. The phrase 'the next step; a dispute's re-drive (queued, running, done)' is dense and context-dependent. Every clause is short, but the structure forces the reader to parse instead of scan.

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 return values, and enumerating the case states partially discharges that. However, ambiguous fragments like 'the next step' are undefined, and the way to distinguish case_id from case_token is left unclear. Adequate for a simple read-only status tool but with noticeable gaps.

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 both parameters are already documented. The description adds only marginal semantics ('the key of the case's account, or the case_token ... without a key'), which is a slightly confusing rewording of the either/or the schema already states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 name 'case_status' and title 'A support case's status' already signal the resource, and the description restates this by enumerating the possible states (open, waiting, answered, closed). It never states a verb like 'retrieve/get the status', so the purpose is implied by the value list rather than declared. It does not explicitly differentiate itself from siblings like support_ask or dispute_result, which only appear as sources of the id.

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?

There is no explicit when/when-not guidance or named alternative. Usage is only implied by the reference to 'the case_token support_ask gave', which hints that this is called after support_ask creates a case. An agent can infer the workflow but the description never states the condition that selects this tool.

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