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

Annotations (idempotentHint=true, readOnlyHint=false, destructiveHint=false) are consistent with the description, which goes well beyond them: Apollo auto-creates missing contacts, duplicate adds return already_present as an idempotent success, activateSequence is best-effort ('a sequence that is already active is left as is'), and Instantly handoffs trigger automatic reply/bounce/unsubscribe state sync. The 'Free: no CampaignStack credits' note is the kind of operational context that saves an agent from making wrong assumptions.

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 disciplined: every sentence carries a distinct fact (resolution behavior, idempotency, best-effort activation, state sync, cost, return statuses, ID lookup routing). No filler or name-restating tautology. It runs long, but the length is justified by the provider-parameterized complexity and the absence of an output schema, which makes the status enumeration load-bearing.

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 an 8-parameter, provider-parameterized mutation with no output schema, this is complete: it fully enumerates possible return statuses including example error codes with their causes (INTEGRATION_NOT_CONNECTED, INTEGRATION_KEY_INSUFFICIENT_SCOPE for non-master Apollo keys, LEAD_NOT_FOUND), explains provider differences, prerequisites, idempotency semantics, and cost implications. An agent has everything needed to decide, invoke, and interpret the result correctly.

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 88%, so the schema carries most parameter meaning. The description adds genuine value beyond it: it explains that leadId is resolved by email on the provider side (the only undocumented parameter), clarifies that campaignId is the provider-side sequence id, and reinforces that emailAccountId is a sending mailbox required only by Apollo. This compensates for the one uncovered parameter without redundant restatement.

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 verb and resource: 'Add one lead to an external provider's sequence,' immediately clarified as provider-parameterized ('apollo sequences, instantly campaigns'). This cleanly separates it from siblings like campaignstack_add_lead_to_external_list (lists vs. sequences) and campaignstack_sync_lead_to_hubspot (CRM sync vs. sequence enrollment) without needing to inspect either schema.

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 gives strong usage context: provider-specific prerequisites (Apollo requires emailAccountId, activateSequence is Apollo-only, skipIfInWorkspace is Instantly-only) and explicit pointers to sibling tools for ID lookups ('Use campaignstack_list_external_sequences for sequence ids and campaignstack_list_external_email_accounts for Apollo mailbox ids'). It does not explicitly state when NOT to use the tool versus the add-to-list siblings, relying on naming, which keeps it from a 5.

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