Veezco

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds the genuinely useful fact that the call consumes no credits, and defines the unit ('one credit is one new lead'), which goes modestly beyond the annotations, though it says nothing about the shape or freshness of the returned balance.

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 short fragments, all load-bearing: resource, cost, and unit definition. It is front-loaded and wastes nothing, though the telegraphic style (no main verb in the first fragment) is slightly terser than ideal.

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 zero-parameter, fully annotated read tool with no output schema, the description covers what is returned (balance and plan), that it costs nothing, and what a credit means. An agent has enough to call it correctly; only the exact response fields are left unspecified.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The definition correctly stays silent on inputs rather than inventing any.

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 names the specific resource — Veezco credit balance and plan — so the agent knows exactly what it gets back. The verb is implicit in the tool name rather than the description, and no sibling differentiation is offered, but the siblings (list_categories, search_companies) are unrelated enough that confusion is unlikely.

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?

There is no explicit statement of when to call this versus alternatives or when not to. Usage is only implied by 'Free, no credits used,' which suggests it is safe to call at any time without cost, but the agent must infer that checking the balance before a credit-consuming action is the point.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context not in annotations: it is free and uses no credits, and it returns the latest collection date. It stops short of describing pagination or result limits.

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 sentences, front-loaded with what the tool returns and followed by cost and usage guidance. Every sentence carries distinct information with no waste.

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 one-parameter lookup tool with rich annotations and full schema coverage, the description is complete: it explains what is returned, that it is free, and how to use the result with search_companies. No output schema is present, but the return value is sufficiently described.

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 single 'city' parameter is fully documented in the schema with an example. The description reinforces the city scope but adds no parameter details beyond the schema; baseline 3 is appropriate.

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 (List) and resource (business categories Veezco already collected) with a clear scope (in a city) and additional return detail (date of latest collection). It distinguishes the tool from siblings by naming its role in relation to search_companies.

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?

It explicitly says 'Use it to pick the exact category name for search_companies,' giving clear context for when to invoke it. It does not state when not to use the tool, but for a simple lookup that is a minor gap.

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

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.