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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond annotations and schema: aggregation semantics ("one lead per response across all forms", i.e., dedup does not include), default ordering ("newest activity first by default"), and masked email handling ("never by a masked email"). These are real behavioral traits an agent could not infer from the parameter schema.

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?

Five sentences, each earning its place: purpose + aggregation semantics, default ordering, filter summary, code-domain management, and ID/masking convention. It is front-loaded with the core definition and does not repeat schema boilerplate.

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 tool with an output schema, the description covers the decision-critical semantics: aggregation, default sorting, code validation, and masked-employee handling. Pagination bounds, the page-local filtering caveat, and the special assignee value "me" remain in the schema, which is acceptable. The complete is modest — it does not name sibling alternatives for raw-record or single-lead access — so very close to fully complete but not absolutely.

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 parameters are already fully documented and the baseline is 3. The description adds value on top by summarizing the filter dimensions in one line (status / assignee / tags / created-at range / keyword / upcoming booking) and by providing the identifier discipline (leadId vs examineeId, never a masked email) that the schema itself does not state. This moves it above baseline, though it still relies on the schema for precise meanings.

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?

The description states a specific verb + resource + scope: "List the leads (CRM records) of the current team" and immediately disambiguates it from siblings with "one lead per respondent across all forms". It also lists what each lead carries (status, assignee, tags, next upcoming booking), so the agent can distinguish list_leads from list_records and list_examinees without opening their schemas.

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?

The description gives clear context: the tool targets the current team's aggregated CRM view, and it adds an explicit prerequisite — "call list_lead_settings first to get the valid ones, never guess." However, it does not explicitly name alternative tools to rule out (e.g., when to use list_records or get_lead instead), so the when-not-to guidance is implied rather than stated.

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