Prepare outreach brief

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds materially beyond that with the suppression flag convention (`suppressed: true`) and, notably, a prompt-injection warning that signal titles/excerpts are untrusted third-party text. It does not discuss rate limits or output sizing, which is why it falls short of a 5.

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 dense sentences, front-loaded with the artifact produced, then the write handoff, then the safety caveat. No filler; each sentence adds a distinct operational fact.

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 5-parameter tool with 0% schema description coverage and no output schema, the description does a good job on output contents, safety, and the save handoff — but the near-total absence of parameter guidance (tone/channels/touches semantics or defaults) leaves a real gap an agent must guess at.

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% and there are 5 parameters, so the description carries the full burden — but it never explains tone, touches (default 4, range 2-6), channels (email/linkedin_note), or the prospect_ids cap of 25. 'Seller context' and 'sequence framework' only loosely gesture at seller_context and touches/channels, leaving required semantics to inference.

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?

States a specific verb ('Prepare') and a specific artifact ('outreach brief'), then enumerates its contents (seller context, per-prospect facts, signals, sequence framework, compliance rules). It also distinguishes itself from the write path by naming sdr_save_prospects for saving drafts, so an agent can tell it apart from siblings without opening schemas.

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?

Makes the division of labor explicit ('It does NOT write the copy — you do') and routes the follow-up action to sdr_save_prospects with the exact field (custom_fields.first_line). It also gives a skip rule for suppressed prospects. It stops short of naming a specific alternative in sibling terms for isolating signals or research, but the context for when to call it is clear.

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