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

Annotations already declare this is a non-read-only, open-world operation, and the description usefully adds that the message becomes visible in the lead's inbox/conversation, that a per-call confirmation is on by default and can be disabled for this tool, and that a Cotlet API key with app access is required. That is meaningful behavioral context beyond the hints, though it stops short of rate limits or failure behavior.

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 of the opening sentences say the same thing ('Text a lead... Shows in the lead's inbox' / 'Sends a text to one lead... shows in the lead's conversation'), so the definition repeats itself before reaching the actionable guidance. It is short overall, but a third of it is redundant.

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 cover the things an agent needs: recipient scope (one lead), side effects (message appears in the lead's conversation), confirmation policy, and credential requirements. Error handling and delivery-confirmation semantics are absent, which is the only real 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 description coverage is 100%, so the schema already documents body, lead_id and to_phone (including the 'Default: primary' behavior). The description's 'Use to_phone to pick one of the lead's numbers' simply duplicates the schema, so the baseline of 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?

The description states a concrete verb and resource: it sends a text/SMS to exactly one lead from the REsimpli campaign number, and it distinguishes itself from the rest of the resimpli_* family (which is lead management, not outbound messaging). It does not name a sibling alternative, and the core idea is restated three times rather than sharpened, which keeps it short of a 5.

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 operational context ('reaches other people: confirm with the user before each call', confirmation can be switched off, needs an API key with app access) but never frames when to choose this over alternatives such as leaving a note or a different messaging channel. Usage is implied by the context rather than explicitly scoped.

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