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

Annotations already declare readOnlyHint, openWorldHint and non-destructive, so the safety profile is covered; the description nonetheless adds useful context beyond them, namely that an empty list is the expected result for an un-traced lead and that a Cotlet API key with access to the app is required for auth. It does not discuss pagination or result limits, so not a full 5.

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?

Front-loads the resource and then the key caveats, and every sentence conveys real information. The opening two sentences are somewhat redundant ('Phone numbers and emails found for a lead' vs 'Returns the phone numbers and emails the skip traces on this lead found'), a minor cost against otherwise tight structure.

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?

With no output schema, the description fully describes the return (phone numbers and emails, empty list when nothing was traced) and the required auth. For a single-parameter read tool whose annotations cover safety, nothing an agent needs to call 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?

Schema description coverage is 100% and the single lead_id parameter is already documented in the schema, including its source ('Lead ID from list_leads'). The description adds no format or syntax detail for lead_id, so the schema carries the load and 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?

Specific verb (get) plus a precisely-scoped resource (skip trace results: phone numbers and emails found for a lead). It explicitly contrasts itself with the sibling that performs the action, stating that it does not start a skip trace and that skip_trace_lead does. An agent can distinguish it from skip_trace_lead without opening 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?

Gives both when-to-use (retrieve results already found for a lead) and the negative condition (a lead with no skip trace returns an empty list, so an empty result is not an error). It also routes the agent to the correct alternative, skip_trace_lead, when the goal is to actually run a trace.

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