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

Annotations only declare readOnlyHint=true, so the description's addition that 'nothing is stored' is genuinely new and confirms the tool is a pure computation over inputs. It also discloses non-obvious behavior: the text carries no statement until one is recorded in the Defamation case, and the answer echoes inputs back in untrusted_business_facts. The prompt-injection warning about reviewer-authored fields is useful behavioral context. Remaining gap: no mention of error conditions, e.g. what happens for an ineligible or already-appealed case.

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 text is one dense block of run-on sentences that repeatedly switches between input fields, output fields, and eligibility rules without headings or ordering cues. It contains a literal duplication ('statement. statement.ask') and refers to output paths like business_facts.by before establishing what the response structure is. The first sentence is front-loaded, but the remainder is hard to parse and would cost an agent reading time.

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 must name the return content, and it does: appealability, recommendation, the untrusted_text to paste, statement guidance, attachment guidance, and echoed business facts. It also covers the Defamation-specific prerequisite that gates the text. It is short only on case_id and on failure modes, but an agent has enough to call this correctly.

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 the object is nested, so the description carries the burden and largely meets it: it explains that business_facts.by is who at the business states the facts, .statement is what is stated, and .documents are file names for screenshots or PDFs. It even supplies a formatting rule ('start it in lower case') and a length-adjacent constraint ('screenshots or PDFs'). case_id is never explained, and statement.ask / attachments are output fields mixed in without markers, which keeps this from a 5.

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 opening clause names a concrete resource and outcome set: for a review Trustpilot kept online, it returns whether the decision can still be appealed, whether an appeal is recommended, and the paste-ready appeal text. That is a specific verb-plus-resource with distinguishable outputs, and the later instruction to pass business_facts to record_appeal implicitly separates this generation tool from the recording sibling. The awkward 'For a review Trustpilot kept online' framing and the scattering of output field names (statement.ask, statement.status, business_facts.by) blur the single-sentence purpose a bit.

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 real usage signal: 'once, within six months' bounds when an appeal is possible, and 'Pass the same business_facts to record_appeal' establishes the workflow order with a named sibling. However, there is no explicit statement of when to use this versus claim_packet, decline_packet, or regenerate_draft, and no when-not-to-use guidance. The guidance is implied through workflow coupling rather than stated.

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