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

Annotations only mark this openWorld, idempotent, non-destructive and not read-only; the description adds the material behavior that annotations cannot express: per-lead credit consumption, free/already-owned leads surfacing first, live collection latency of 15-30 minutes with incremental results, and the requirement to re-call with identical arguments. That is exactly the kind of cost and asynchrony an agent needs before invoking.

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-loaded with the outcome (what leads you get) before cost, naming conventions, and the live-collection retry path. Dense but mostly earning its place; the category pluralization guidance partially duplicates the category param's own schema description, which is the only real redundancy.

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 carries the return shape ('contacts, what Veezco measured on their website and an opening line for the call') and the partial-results semantics of a live collection. Combined with full schema coverage, an agent has everything needed to call it and interpret a thin first response.

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 coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: category naming conventions in Italian vs. English, the fact that count is total leads including free ones, and the filtering rule that criteria only select what Veezco actually measured. It stops short of explaining the country param's role in triggering a new collection, which the schema does cover.

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 (find) and resource (local businesses/companies), plus the exact scope (one city, one category) and the payload returned: contacts, measured website data, and an opening line. It is clearly distinct from get_credits and list_categories, which are referenced as supporting steps rather than alternatives.

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 explicit sequencing ('Call list_categories first to get the exact names already collected in that city'), the retry protocol for uncached city/category pairs, and the cost model ('Each NEW lead costs 1 Veezco credit; leads you already received are free and come first'). It also warns that filters only match measured data so an unreadable website never satisfies no_meta_pixel — a concrete when-not caveat.

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