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

Annotations already declare write/destructive/non-idempotent/openWorld, and the description adds genuinely new behavior: the 10000-per-call ceiling, normalization of single-leading-zero numbers to the list's calling code, and that duplicates and invalid numbers are counted rather than added. "Sends nothing" is a valuable disclosure that no messages are dispatched, though auth requirements and the response payload remain unstated.

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?

One dense paragraph with the write tag, the target resource and the size limit front-loaded, and every clause conveys a distinct fact. It is slightly packed with parenthetical detail, but no sentence is filler.

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 4-parameter mutation with no output schema, the definition covers the input shapes, the batch limit, normalization rules, and the duplicate/invalid outcome plus the no-send guarantee. What an agent cannot learn is the exact return value (presumably added/skipped counts) and any permission prerequisites.

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 0%, so the description must carry parameter meaning and it largely does: `items` accepts bare numbers or {"msisdn", "vars"} objects, `source="customers"` selects customers with a phone, and sms_list_id/sms_list_uuid identify the target list. The only gap is whether the id and uuid are alternatives and whether at least one is mandatory given required=0.

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 ("Adds numbers to a saved list") and immediately names the list identifier parameters. The channel prefix plus the write tag distinguish it from add_email_list_members, add_tg_list_members, add_voip_list_members and add_wp_list_members without opening any schema.

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 spells out the two mutually exclusive input modes -- an `items` array or `source="customers"` -- and gives the per-call cap of 10000, so an agent knows how to invoke it. It does not state when to prefer list-import over send_sms or create_sms_campaign, nor that one of sms_list_id/sms_list_uuid is effectively required, but the operational context is clear.

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