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

Annotations already declare readOnly/non-destructive/openWorld, so the description's added value is the API's quirks: the default-to-today behavior without start_date and the hard 400-day range limit. It also discloses the permission model (Profile key vs Agency key scoping), though it says nothing about rate limits or result volumes.

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?

Three dense, front-loaded sentences with no filler — resource first, then the hard constraint, then the auth scoping nuance. Slight duplication: enumerating lead types restates the lead_type enum already in the schema, and the trailing 'GET /leads' is decorative.

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 23-parameter, no-output-schema list tool, the description covers the two things an agent could get wrong (missing start_date, over-long ranges) and the key-scoping rule. Pagination behavior is handled by the schema's next_page/per_page descriptions, so the remaining gap is minor.

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%, so the baseline is 3, but the description adds genuine meaning on top: why start_date is required, the 400-day interaction between start_date and end_date, and the authorization semantics of account_id/profile_id. That exceeds what the schema's per-field descriptions convey.

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 (List) plus resource (tracked leads), enumerates the lead types returned, and summarizes the payload (attribution, contact details, values, transcripts). This clearly separates it from siblings like whatconverts_get_lead (single lead) and whatconverts_create_lead.

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 concrete invocation context: start_date is mandatory because the API otherwise defaults to today, ranges are capped at 400 days, and key type determines whether account_id/profile_id narrowing is available. It never names an alternative sibling verb, so it stops short of full when/when-not routing.

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