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

With no annotations, the description carries the full burden and does it well: it discloses the human-in-the-loop guarantee, the automatic-refusal behaviour when the same contact has already been told the same thing, and the plain-text constraint. It doesn't say what the tool returns (draft ID? error shape on refusal?) or what permissions are needed, so it falls short of complete.

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 critical safety fact ('NEVER sent automatically') is front-loaded in sentence two, and each subsequent sentence covers one distinct concern: language/format, content guidance, fingerprint. The final sentence is long and packs the fingerprint plus dedup behaviour together, so it's dense rather than wasteful.

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 annotations and no output schema, the description covers safety, formatting, language, and dedup, which is most of what matters. The main gap is that it never indicates what a successful call produces (a draft handle the agent could pass to send_report later), which an agent might reasonably need.

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 already 83%, so the baseline would be 3, but the description adds real meaning: the fingerprint is explained with a concrete example format and its de-duplication consequence, and the body's language and plain-text requirement are spelled out. Optional params like run_id and site_id get no explanation in the description, relying entirely on the schema.

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 a specific verb and resource (draft an email report to a site contact) plus the crucial placement detail — it lands in the panel for human review. That, combined with 'NEVER sent automatically', cleanly separates it from the send_report sibling without naming it.

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?

It gives concrete conditions for use: write in the contact's language (pointing to list_contacts), plain text only because it goes out as email, and pass a fingerprint for de-duplication. It doesn't explicitly name send_report as the follow-on step or state when drafting is inappropriate, which keeps it below a 5.

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