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

Annotations only give generic safety flags (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds genuinely new behavior: notYetEnrolled skipping, email-only sequences skipping unknown-email people, mixed sequences deferring email steps, findEmails being a metered lookup, and the no-approve/no-send boundary. This is substantial context beyond the structured fields.

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?

Dense but front-loaded, leading with the action and target. Every clause adds operational meaning (skip rules, metering, lifecycle boundary). A bulleted or segmented form would scan better, but there is little wasted text.

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 10-parameter mutation tool with no output schema, the description covers selection, targeting, side effects, and lifecycle limits well. The main gap is no indication of the return shape (e.g., counts of added/skipped people) and the omitted maxEmailLookups/template values, though nothing an agent needs to invoke it correctly is missing.

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 only 10% schema description coverage across 10 params, the description carries the burden and mostly delivers: it explains competitor, playId, candidateIds, notYetEnrolled, sequenceId, name, template, and findEmails semantics. It omits maxEmailLookups and lists only 3 of the 7 template enum values (linkedin | email | linkedin_email), leaving gaps an agent must infer.

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 precise verb+resource: pick people from the account universe and add them to one sequence. It names the selection modes (competitor, playId, candidateIds), the two targets (existing sequenceId vs new draft), and routes to specific siblings (list_sequences, save_sequence_draft, set_sequence_status), so an agent can distinguish it from add_leads, add_company_contact, or find_people without opening a 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?

Explicit when-to-use branches: an existing non-archived sequenceId from list_sequences, or a new draft via template (then edit with save_sequence_draft). It also states when email-only vs mixed sequences behave differently and clarifies that adding never approves, launches, or sends, deferring that to set_sequence_status.

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