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

Annotations declare non-readOnly, non-destructive, non-open-world, non-idempotent, but the description adds the crucial behavioral facts the annotations cannot convey: the campaign is created in DRAFT state and nothing is sent until campaign_launch. It also clarifies the call has a single narrow effect ('creates the campaign and nothing else'), so the agent won't assume side effects like sequence or account configuration.

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?

Front-loaded with the key fact (draft, nothing sends until launch) and organized around sourceUrl paths. Slightly redundant: 'Nothing sends until campaign_launch' is restated by 'it only sends after campaign_launch' at the end, costing a bit of density.

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?

With only 2 fully-described params and no output schema, the description supplies the missing workflow context — post-creation steps (flow_set, campaign_update, campaign_launch, campaign_upload_leads) — so an agent knows exactly where this call sits in the campaign-building sequence.

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 coverage is already 100%, so the baseline would be 3; the description earns above that by explaining sourceUrl's accepted URL families (LinkedIn/Sales Nav/Recruiter/group/event/post) and the strategic choice of when to supply it versus omitting it. It doesn't add format specifics beyond the schema's own inference note, keeping it at 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?

States a specific verb+resource ('Create a DRAFTED campaign') and immediately scopes it: the draft is inert until campaign_launch. The final sentence enumerates what this call does NOT do (sequence, accounts/limits, sending), cleanly separating it from flow_set, campaign_update, and campaign_launch.

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?

Explicit routing: pass sourceUrl for URL-harvested prospects, omit it and use campaign_upload_leads for CSV, and never start with campaign_duplicate unless the user named a campaign to copy. This is a textbook when-to-use / when-not / alternative specification.

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