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

With no annotations at all, the description carries the full disclosure burden and largely succeeds: it discloses the async 202 response, a human fetching and checking evidence, email follow-up either way, and (via the context param text) that context is never used to rank. Unstated failure handling and response timeframes prevent a 5.

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 sentences with high information density — workflow, status code, and access policy each earn their place. The unexplained 'INFLUENCE —' prefix occupies the front-loaded position without adding functional value, costing the fifth point.

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?

The workflow and access model are well covered, but an agent cannot reliably invoke the tool: the required slug is undefined, what a 'finding' refers to in this domain is never clarified, and with no output schema the agent has no sense of the successful result beyond a bare 202. Critical invocation details are missing.

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 coverage is only 20% (just the context parameter), so the description was obligated to compensate. It explains claim and evidence_url ('Send the claim in words and a URL that evidences it'), but the required slug parameter is entirely undefined and contact is only inferable from the 'emails you either way' statement. That is a significant gap for a required parameter.

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 the action — submit a dispute of a system finding by sending a claim and an evidence URL — and differentiates it from simple reporting by disclosing the human-mediated evidence-check process. The 'INFLUENCE' prefix and quoted phrase are informal, and the domain object 'finding' is never explicitly defined, which keeps this from a 5.

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?

Provides one genuinely useful access guideline: open to any paying caller, no ownership proof needed before disputing data. However, it never names alternatives among many plausible siblings (report_correction, correct_facts) nor states explicit selection conditions; usage context is implied rather than contrasted.

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