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

No annotations are provided, so the description carries the full burden and meets it: it discloses the two paid/free tiers and their credit costs, the confirm:true cost-confirmation flow, and interpretation caveats (contractValue excludes frameworkValue, association wins counted in full per member, coverage from 2018 with no direct purchases). These are exactly the behaviors an agent could not infer otherwise.

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?

The body is well front-loaded with sections (tiers, interpretation caveats, when-to-use, alternatives, cost confirmation), but roughly seven lines of keyword stuffing ('autoritate contractantă, primărie achiziții...') occupy prime space and contribute little to an agent deciding or invoking the tool. Useful density is high, but a meaningful chunk of the text does not earn its place.

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 no-annotation, no-output-schema tool this is complete: it covers both tiers and their costs, the confirmation protocol, coverage limits, and value-interpretation traps, leaving nothing an agent needs to call it correctly unstated.

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 adds real meaning beyond the schema: it tells the agent where to obtain taxId (search_companies or the /autoritati pages) and contrasts the two detail tiers by output size and cost. The added value is genuine but modest, since the schema already defines all three fields.

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 and resource: 'Profilul de CUMPĂRĂTOR al unei autorități contractante românești' from SEAP/SICAP data, with the exact scope (cât atribuie, cui, pe ce domenii CPV). It explicitly names what it is not by routing to get_cpv_market, get_company_contracts and get_company_competitors, so an agent can distinguish it from siblings without opening any 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?

A dedicated 'Când îl folosești' section lists concrete trigger queries ('Cine vinde la Primăria X?', offer preparation, journalism/due diligence) and closes with explicit alternatives and the condition selecting each. Nothing is left to inference.

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