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

With no annotations present, the description carries the full burden and it does so well: it flags 'THIS SENDS', notes that the connection request counts against the user's daily limit, and returns a draft_ handle that lets the agent skip list_scheduled. What it doesn't cover is failure behavior (what happens if the send is rejected or the daily limit is already hit) or the permission/auth model.

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?

Information is front-loaded: purpose first, the 'THIS SENDS' warning second, then the permission rule, then args. Every sentence carries weight. Minor deduction for the redundant title repetition at the top and slightly loose line breaks that add no value.

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?

Given no annotations, no output schema, and zero schema coverage, the description covers purpose, consent semantics, rate-limit impact, return value, and all three parameters — enough to call it correctly. The remaining gap is error/failure handling and whether an approval can be reversed beyond the referenced cancel_scheduled.

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 0%, so the description has to define all three parameters itself, and it does: handle is tied to its producing tools; override_text spells out the non-obvious omission-vs-empty-string distinction (omit = send drafted text, "" = no note at all); send_at documents the literal "now", ISO-8601 with an offset plus an example, and the omit-and-Iridium-chooses default. This is meaningful semantics the schema cannot supply.

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 verb (approve) and a specific resource (one connection-note draft) and states the follow-on effect (schedule/send it). Naming the draft type as 'connection-note' distinguishes it from the sibling approve_comment_draft, approve_reply_draft, and approve_content_draft tools, so an agent can route correctly without opening a 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 explicitly sets the when/when-not condition: 'Call it only when the user has explicitly asked for this specific draft to go out. Finding or drafting something is not permission to approve it.' That exclusion clause is exactly the guardrail a tool with an irreversible send side effect needs, and it also points at the source tools (list_drafts, discover_prospects, run_outreach_pipeline) that produce the handle.

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