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

The description adds substantial behavioral detail beyond the annotations, including pagination semantics, draftId/reviewFingerprint invalidation, paused-send status behavior, the 30-minute expiry window, and the fact that resolve may call the LinkedIn provider and update cached reachability. It does not elaborate the destructiveHint=true annotation or describe any irreversible effects, but it does disclose the key side effect of the resolve action and the simulated sandbox 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?

The description is front-loaded with the three action modes and then adds dense operational details, with essentially no filler. However, it is a long single paragraph covering multiple modes, so clearer structural separation of preview, status, and resolve would improve scanability.

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 complex seven-parameter tool with no output schema, the description is remarkably complete: it explains preview return fields and paging, status semantics and expiry, resolve side effects, error codes, and simulated sandbox behavior. An agent has enough information to select the right action and interpret the main results.

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?

With 0% schema description coverage, the description meaningfully compensates by explaining the three actions, the batchId returned by sourcing_outreach_send, and the paging role of recipientOffset/recipientLimit/bodyOffset. It does not explicitly define sessionId or channel, but channel is evident from the opening email/LinkedIn wording and sessionId is implied by 'owned session'.

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 opens with a specific multi-action purpose: previewing personalized outreach, reading batch status, or resolving LinkedIn reachability for an owned session. It names the resources and scope clearly and explicitly references sourcing_outreach_send, so an agent can distinguish the review tool from the sending tool.

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 concrete usage rules for status: batchId must come from sourcing_outreach_send, paused sends are indicated by pending above 0 with idle activity, and sending resumes via sourcing_outreach_send within the 30-minute confirmation window. It also explains preview invalidation after a changed draftId or reviewFingerprint, though it does not compare this tool against all sibling tools such as sourcing_review or sourcing_read.

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