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

The description goes far beyond the sparse annotations (readOnlyHint=false, etc.) by disclosing critical behaviors: non-idempotent nature (returns added/skipped counts), limits, email validation rules, copy style requirements (no em-dashes, subject length, word count), punycode requirement for non-ASCII domains, skip reasons, and the fact that contacts added to a launched campaign remain inert until outreach_launch_campaign is called again. This is comprehensive and consistent with annotations.

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?

Despite being a long paragraph, every sentence earns its place. It is front-loaded with the primary action, then systematically covers limits, usage on launched campaigns, content requirements, writing style, punycode, return values, and post-add behavior. No filler or redundancy; the density is appropriate for the tool's complexity.

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?

This description is exceptionally complete for a tool with no output schema. It explains not only what happens on success (count of added contacts) but also all skip reasons (invalid email, duplicate, copy too long, campaign full, already_contacted), the requirement to re-launch for live campaigns, and content constraints. The description fully covers the tool's behavior, limits, and edge cases, leaving few questions for the agent.

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?

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds meaningful semantics beyond the schema: per-contact copy requirements (subject and body length, style, word count), one-contact-per-domain limit, and the requirement for real, researched emails. It does not duplicate every schema field but enriches the meaning of the contacts array and its properties, justifying a 4.

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 'Add contacts with per-contact email copy to a campaign,' which is a specific verb and resource, clearly distinguishing this tool from the many read-only analytics siblings. It further clarifies its scope by detailing constraints (max 100 per call, 500 per campaign) and that it works on both draft and launched campaigns, leaving no ambiguity about its function.

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?

The description provides clear usage context: it works on a draft campaign or an already-launched one, explicitly noting that adding to a launched campaign is 'how you top a live campaign up with fresh prospects.' It also implies exclusions by stating limits and the need for researched emails, but it does not explicitly name alternative tools or state when-not-to-use conditions. Thus it earns a 4 rather than a 5.

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