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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context on top: a list is a rule, so membership is live and changes as leads move, and results are scoped to this person's view. That live-membership caveat is exactly the kind of trait structured fields cannot express.

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?

Two short sentences with the core scope front-loaded and a useful parenthetical explaining what a list is. The clause 'with how many there are in all, this person's view only' is grammatically tangled and takes a second read, which is the only real structural flaw.

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 does the needed work by saying the response contains the leads plus an overall count, and it flags the shifting membership that would otherwise surprise callers. Pagination is handled by the cursor parameter in the schema, so its absence from the description is acceptable.

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%, with limit, cursor and list_id all documented in the schema itself, so baseline 3 applies. The description adds only that the response includes an overall total, which is return-value context rather than parameter meaning, and says nothing about limit or cursor semantics beyond 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 names a specific resource and scope: leads on one saved list, plus the total count and a per-user view restriction. It distinguishes itself from detail-fetching by pointing to get_lead for per-lead data. It stops short of contrasting with search_leads, which is the most likely confusion point.

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?

Guidance is implied by the phrasing 'one saved list right now' and the explicit follow-up 'Use get_lead on any of them for the detail.' There is no statement of when not to use it, e.g. that cross-list or criteria-based lookups belong to search_leads, so the agent must infer the boundary.

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