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

No annotations are provided, so the description carries the disclosure burden. The NOTE adds genuinely useful behavioral context — v2 uses POST /leads/list rather than GET, and the API campaign field is `campaign`, not the schema's `campaign_id`. Still, it leaves read-only guarantees, pagination, and return format undisclosed.

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?

One precise sentence plus a compact, clearly flagged NOTE. Every element earns its place, and the critical version/field caveat is visually separated so the agent cannot miss it.

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 4-parameter tool with zero annotations and no output schema, the description covers the core operation and a key failure-mode pitfall. But it omits limit semantics and any return-shape or pagination guidance, leaving an agent to guess at the response format. It is minimally viable, not complete.

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 0%, so the description must compensate. It does clarify that campaign_id, list_id, and search act as optional filters and warns that the API expects `campaign` rather than `campaign_id`. But `limit` is never mentioned, leaving its units and pagination meaning undocumented anywhere.

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 — 'List leads' — with precise optional filter dimensions (campaign, list, search text). The scope is clear and it is obviously distinct in kind from single-item getters like get_lead and from search_leads_by_email, though it never names a sibling explicitly.

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?

Communicates the intended use — listing leads with optional filters — and the NOTE gives an explicit invocation rule (use POST, use `campaign`). However, it offers no when-not-to-use guidance and never routes the agent to alternatives such as search_leads_by_email or get_lead, so the context is clear but exclusions are absent.

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