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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: the call is free (no credit spend) and returns only masked contact availability rather than paid contact details, which directly shapes what the agent can conclude from a response. It could go further on pagination or how the masking manifests, but the cost and data-masking traits are the important disclosures.

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?

Two short sentences, front-loaded with the primary identity of the tool and followed immediately by the most consequential constraint (masked, not paid, data). No filler or repetition; every clause carries information.

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 and a large nested filter schema, the description should at least characterize what "masked contact availability" looks like in the response so an agent knows how to interpret and relay it. It covers the cost model and masking rule adequately, but leaves the return shape and filter-field coverage underspecified for a tool of this complexity.

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 effectively 0% for a nested filters object with roughly 25 properties, so the description must carry the semantic load and largely does not. "Using all dashboard filters" hints that the filters object mirrors the dashboard filter set, but nothing explains page versus limit versus max_results, or that include_emails/include_phones likely cannot yield real contact data in a preview.

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?

"Free search preview using all dashboard filters" states a specific action (preview) and resource (leads/search) plus the distinguishing trait that it is free, which implicitly separates it from the paid search_leads sibling. It stops short of naming search_leads directly, so an agent must infer the pairing from the word "preview".

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 word "preview" plus "free" implies the intended use case of sampling results before committing to a full search, but the description never states when to use this instead of search_leads, get_search_count, or get_search_results. No exclusions, prerequisites, or explicit alternative routing are given.

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