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

Goes well beyond the annotations by disclosing the irreversible consequence ('entries are never removed or weakened later, so this cannot be undone in HelpWell') and the side effect on matching contacts. This materially reinforces destructiveHint=true and idempotentHint=false with operational meaning.

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, front-loaded with the action and its consequence, with zero filler. Every sentence contributes (what it does, when to use it, permanence).

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 destructive, non-idempotent mutation the description covers irreversibility and the consent side effect well. It omits operational details like the 5000-entry batch cap and how partial failures are reported, but with no output schema and a partly-documented schema this is a minor gap.

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 50%; the schema already documents the reason enum and the optional per-entry reason. The description loosely frames what 'entries' are (exported addresses) but adds no syntax, format, or batching detail beyond the schema, so baseline 3 is appropriate.

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 ('Adds addresses to the suppression list') and clarifies the effect ('Matching contacts become unsubscribed'), which cleanly separates it from read-only siblings like get_suppression_summary and list_blocked_senders.

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?

Gives a concrete use case ('an unsubscribe or bounce export from another email tool') that tells the agent when this tool applies. It does not name an alternative tool or state when-not to use it, so it falls short of the top band.

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