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

Beyond the annotations it adds the cost ('Free'), the server-enforced daily ceiling of 20 inbox drafts ('a batch is never bigger'), and the durable consequence of passing skip ('never offered again'), which explains why readOnlyHint is false on an otherwise list-shaped tool. Returned companion data (offer, voice, sender, draftsLeftToday) is also disclosed. Nothing contradicts the annotations.

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 eligibility rule is front-loaded, which is good, but the sentences are run-on and cluttered with parentheticals ('the product's own users report (routines/users.md)', 'as it is'), and the ranking clause 'those from a channel nobody paid for' is genuinely hard to parse. Content earns its place; the phrasing does not.

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 shape itself (person, email, name, did, from, record, plus offer, voice, sender, draftsLeftToday), which is a substantial contribution. Ordering and exclusion rules are covered. Some wording, such as the secondary ranking rule, remains ambiguous enough to leave an agent guessing at the intended order.

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%, so the schema already documents both parameters, and the description largely restates them ('people the founder will not write to, never offered again'). It does add the cap of 20 for a batch, but count's default of 10 is only in the schema. Baseline 3 fits.

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 makes the resource specific: 'People to write one personal note to' drawn from signups in the last 14 days who are unpaid, quiet 2 days, and either unactivated or stopped after one go. The selection criteria are distinctive enough that an agent can separate this from launch_targets or outbound_targets. It never names a sibling tool, though, so full differentiation is left implicit.

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 sets the conditions implicitly but thoroughly: who qualifies, who is excluded (founder's own, test accounts, already-drafted, skipped), and how the list is ranked. It also points forward to record_action once a draft exists, which is real workflow guidance. There is no explicit 'do not use when' or named alternative for overlapping target tools.

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