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

Annotations are entirely absent, so the description carries the full burden — and it delivers: recall-focused rather than shortlist behavior, measured language-dependent recall asymmetry (75% vs 25% on 36 probes), inclusion of notices lacking cpv/nature rather than dropping them, multi-lot collapse behavior, and the guaranteed coverage block in responses. This exceeds what any annotation set would have provided.

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 content is dense and nearly every sentence carries operational value, which is defensible for a 26-parameter tool. However, it front-loads a long per-country translation vocabulary list for road-construction terms before the critical guidance (translate the query yourself, recall expectations, tell the user the coverage number), which is buried in the middle-to-late portion. Reordering to lead with the language-recall instruction and the coverage-reporting requirement would make the most important behaviors reachable first.

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 annotations and no output schema, the description covers parameter semantics, workflow position, edge cases (sources without cpv/nature), output shape hints (compact cards, summary_cut, fields='full'), and the coverage block. The remaining gaps — limit/pagination semantics, value_band, cpv_divisions, and expand_languages — are real but minor given how thoroughly everything else is documented.

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 0%, and the description compensates by explaining formats and semantics for roughly 20 of 26 parameters: countries ('ISO3 'LTU', or 'LT''), cpv prefix rules, status enum values ('open' default, 'forthcoming', 'any'), ISO date formats for deadlines, EUR conversion with exclusion of unpriced notices, strict flags, nuts NUTS2 granularity, and the query-vs-queries distinction. Only value_band, cpv_divisions, expand_languages, kind, and limit receive no explicit treatment.

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 title states the verb+resource directly ('Search tenders and grant calls') and the description opens with 'Hybrid search' confirming the discovery function. It positions itself as the first step in a pipeline by naming the follow-up siblings ('Then get_opportunity and read_document'), making its role unambiguous relative to the sibling set.

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?

Explicit when-to-use triggers are given: 'use it when the user asks specifically for grant calls' for type, 'Scope by country — EU-wide ~10x' for performance, and 'exclude_results=true to drop award notices for things already decided'. It also states consequential behavior of filters (notices excluded from value filters rather than guessed, region filters excluding notices with unstated location), which tells the agent what will happen when it applies them.

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