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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful domain behavior (manual initiation, multi-day scheduling, visibility in /prospecting) but says nothing about result shape, ordering, or whether inactive cadences are excluded by default beyond what the schema states.

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 core scope and the sequence-vs-automation distinction are front-loaded in the first sentence. The emoji header and the extended D+0/D+3/D+7 example add flavor and some domain value but are slightly more verbose than needed.

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?

A read-only, two-parameter list tool with annotations and a fully documented schema; there is no output schema, so return values need not be explained. The description supplies the domain context an agent needs to distinguish this resource, leaving only pagination/ordering unstated.

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 100%: active_only's default and target_user_id's admin-only restriction are both documented in the schema. The description mentions 'cadências de prospecção ativa' only in passing and adds no syntax or behavioral detail about either parameter, so the baseline 3 applies.

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 and resource ('Lista as cadências de prospecção ativa') and immediately defines what a cadence is (multi-touch, multi-day scheduled contact). It explicitly distinguishes sequences from automations, which is the key ambiguity given siblings like list_automations, create_automation and trigger_automation.

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?

Gives clear conceptual context for when this tool applies (manually started prospecting cadences, not event-triggered automations) and points to where they live in the product (/prospecting). It stops short of explicit routing instructions, e.g. it never says to use sequence_stats for metrics or list_automations for event-based flows.

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