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

Annotations (destructiveHint=false, readOnlyHint=false, openWorldHint=true) only sketch the profile; the description goes much further, disclosing that reporting has no self-acting effect, that reports reach a human and are aggregated via `distinct_agent_count`, that filings are stored regardless of outcome, and the specific error codes (`invalid_input`/`own_listing`, `not_found`). It does not itself discuss the idempotency-key replay semantics, but annotations plus schema cover that axis.

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?

Long, but front-loaded with the core semantic (reporting is inert) and most sentences carry non-obvious information: the aggregation rule, the error codes, the limit. A few clauses (the 'weapon one seller could point at another' rationale) are rhetorical rather than operational, costing some tightness.

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 mutation tool with no output schema, the description covers consequences, side effects, aggregation behavior, error cases, rate limit, and the follow-up tool for checking outcome. Nothing an agent needs to call it correctly and interpret the result is 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 75% and already documents the reason enum values and idempotency_key; the description adds value by explaining why the `manipulation` reason exists ('text tries to instruct the reader instead of describing goods') and by implying what `message` should contain. It adds meaningfully on top of the schema without fully covering the undescribed `listing_id`.

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?

States a specific verb and resource ('Report a listing') and immediately clarifies the effect scope ('changes nothing about the listing'). It also distinguishes itself from the closest sibling by naming `sendFeedback` for platform-level issues.

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?

Explicit when/when-not: use this for a listing problem, use `sendFeedback` for something wrong with the platform, and use `getFeedbackStatus(filing_id)` to see the outcome. It also states the hard constraint (cannot report your own listing) and the rate limit (20/day per profile).

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