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

Annotations already declare this is a read-only, idempotent, non-destructive call, and the description adds real value on top: the call is 'Free', the status lifecycle values, the polling cadence while not ready, and the cost semantics of the unverified count. It doesn't explain pagination for contents/jobs or whether the response changes shape per status, which keeps it from a 5.

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 status enum and resource are front-loaded, and the polling instruction sits at the end where it belongs. The middle sentence is a dense run-on ('progress of the export, of the guessed email addresses and of the email verification') that takes a second pass to parse.

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 carries the return-value burden and does enumerate the main response groups, plus the polling and cost behavior needed to use it correctly. The exact nesting of the progress objects and the structure of contents/jobs remain unstated, which is the main residual 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 100% and listId already documents its UUID format and provenance (create_list or list_lists). The description adds nothing about the parameter itself, so the baseline 3 applies.

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?

It names the resource (a list) and the exact payload the call returns: status with its full enum (creating, ready, filling, failed), rows, credits spent, export progress, email-check progress, contents and latest jobs. That is far more specific than sibling tools such as get_list_items or get_list_file, which return different projections of the same resource.

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 explicit operational guidance for the non-ready case ('call it again every 10 seconds or more') and points to verify_list_emails to interpret progress.emailCheck.unverified. It stops short of naming when to prefer get_list_items or get_job instead, so the routing to alternatives is implicit rather than stated.

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