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

Beyond the annotations, the description discloses that USPS verification is configuration-dependent, that usps_checked reports whether it ran, and that format checks do not prove deliverability — precisely the caveats an agent needs. The append semantics and 300-recipient ceiling are also stated. It is consistent with the supplied hints (additive write, not destructive, not idempotent), though it never warns that re-running the same import will duplicate recipients.

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?

It is front-loaded with purpose before caveats and exclusions, and essentially every clause carries distinct information. The single dense block is harder to scan than it needs to be, and the returns sentence is partly redundant given the output schema.

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 nested-schema import tool this is close to complete: input modes, verification caveat, append limit, negative scope and return summary are all present, and the output schema covers the return shape in detail. Missing only practical prerequisites such as required account permissions and how row-level failures affect the partial import.

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 100%, so the schema already documents all three parameters and the baseline applies. The description adds only one genuine semantic detail beyond it — that an existing list_id appends rather than replaces, bounded at 300 — and adds nothing about the address_file object's fields or the text-line format beyond what the schema states.

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 opens with a specific verb and resource ('Imports US postal recipients ... into a saved list') and enumerates the accepted input formats (pasted text, CSV, XLSX), so an agent knows exactly what the tool does. It does not name a sibling tool it competes with (e.g. create_mailing vs. fix_address), leaving differentiation to be inferred from the negative scope sentence.

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?

Clear usage context is given: supply list_id to append, cap of 300 recipients, and an explicit 'Not for' clause ruling out email, non-US addresses and purchased/rented lists. What's missing is a named alternative for the related cases it touches, such as routing bad addresses to fix_address or list creation to create_mailing.

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