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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds genuinely useful context on top of that — the delivery channel, the mandatory opt-in gate, and the negative constraint about channel member counts. It still omits behavior when a target is not opted in (silent skip vs. error) and any rate or volume limits.

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?

Three tight sentences with the core action front-loaded and no wasted phrasing. The closing constraint sentence is short and load-bearing rather than 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 side-effecting outbound-notification tool with no output schema, the description leaves return behavior and partial-failure handling unexplained (e.g., what the agent gets back per recipient, whether delivery is batched). The opt-in and channel constraints give it a workable floor, but the mutation outcome is under-described.

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% and all three parameters carry their own descriptions, including the mint-vs-handles alternative and the 500-char message limit. The description adds nothing about parameter meaning beyond 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 gives a specific verb and resource ("DM hired KOLs via @CrewPay_Bot"), so an agent immediately knows this sends outbound messages rather than managing launches or hires. It also draws a boundary by excluding channel-member-count logic, though it never names a sibling tool the agent might confuse it with.

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?

Clear preconditions are stated: recipients must have linked Telegram, sent /start, and enabled alerts, which tells the agent this cannot be used for arbitrary outreach. It does not say when in a workflow to call it (e.g., after crew_autohire or crew_launch) or what to do if no one is opted in.

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