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

With annotations already marking the tool destructive and open-world, the description adds critical behavioral context beyond them: sending is irreversible, may contact external recipients, and can return simulated:true for sandbox accounts that delivered nothing. It also discloses the recovery window and expiry behavior, which directly affects how the agent should handle retries.

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 description is dense but front-loaded, starting with the action and its approval prerequisite before moving into first-confirmation requirements, recovery behavior, and return semantics. Every sentence provides operational value for a complex, irreversible action.

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?

There is no output schema, but the description still explains the meaningful return values: batchId, recipient count, and sending/resumed/replayed/confirmed_not_started status, plus the simulated flag. Given the tool's destructive, open-world nature and six parameters, the description covers the essential context an agent needs before invoking it.

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 carry parameter meaning, and it does: it explains sessionId, channel, draftId, reviewFingerprint, linkedinRiskAcknowledged, and batchId roles across the first-confirmation and recovery flows. It does not restate formats or types already present in the schema, but it compensates well for the lack of parameter descriptions.

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 uses a specific verb and resource: starting outreach sends through a connected email or LinkedIn account. It clearly distinguishes the first-confirmation path from the batchId recovery path, so the agent can tell exactly what operation this tool performs and when a different path applies.

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 states the prerequisite explicitly: the user must have reviewed every page of the preview and approved the exact sender, recipients, and messages. It also gives clear alternative usage: first confirmation requires sourcing_outreach-provided sessionId, channel, draftId, and reviewFingerprint, while recovery uses a confirmed batchId within 30 minutes before a 409 confirmation_expired failure.

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