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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description nevertheless adds real value by disclosing the auth requirement (a plan bearer token, explicitly not x402) and a return-content constraint (contact data is omitted) — both facts the agent would otherwise only discover at runtime.

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 auth constraint front-loaded and no filler. The brevity is appropriate, though the telegraphic phrasing ("never x402" as an unexplained protocol reference) trades clarity for compactness.

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?

For a read-only, non-destructive single-record lookup with annotations carrying the safety profile and no output schema, most baseline needs are met and the contact-exclusion note is useful. What is missing is how to obtain a valid dispute_id and what the returned status values look like.

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%, so the description must compensate for both parameters. It clarifies the token parameter as a plan bearer token that is not x402, but says nothing about dispute_id — no format, no source, no example — leaving the sole required parameter undocumented anywhere.

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?

"Status of one dispute" identifies the resource and makes clear it returns a single record rather than a list, which implicitly separates it from dispute_submit. However, it uses a noun phrase with no verb and never states the mechanism (retrieval), so an agent must infer the operation.

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 guidance on when to call this versus siblings such as dispute_submit, history, or changes_since, and no prerequisites are stated. "Plan bearer token, never x402" describes auth, not usage context, so the agent is left to infer when this tool applies.

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