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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the useful detail that it validates without returning notices, i.e. a validation-only result rather than data. It does not say what a failure/validity response looks like, but that is partly the output schema's job.

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?

A single compact sentence that front-loads the action and resource, with every clause earning its place (the 'without returning notices' clause carries real information about output).

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?

An output schema exists, so return-value explanation is not required. For a one-parameter validation tool this is close to adequate, but it omits any hint of how to interpret a validation result or what makes a query invalid. Adequate but with clear gaps.

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%, so the schema carries no meaning for 'query'. The description compensates partially by identifying the expected format as 'TED expert-search syntax', which is genuinely useful semantics, but it gives no examples, constraints, or escaping rules for that syntax.

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+resource: validating TED expert-search syntax, with the added scoping note that it does not return notices. This clearly distinguishes it from the search_* and count_tenders siblings, which retrieve data rather than validate a query. It stops short of naming those siblings, but the purpose is unambiguous.

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 when-to-use guidance or reference to alternatives. The implication that you run this before a search to pre-check syntax is inferable but never stated, and no conditions or exclusions are given.

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 readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds real behavioral value beyond that: it returns a count rather than a list, it is cheap to call, and scope defaults to ALL so date ranges span the archive. Return shape is covered by the output schema, so nothing critical is missing.

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-loads the core purpose in the first clause, then adds filter routing and a usage tip in two short sentences. The parenthetical and tip both earn their place, though the tip is slightly advisory rather than definitional.

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 7-parameter count tool with an output schema and full annotation coverage, the description supplies the key non-obvious facts: no listing, cheap, scope default ALL. The main residual gap is parameter-level detail, which it offloads to a sibling rather than stating outright.

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%, so the description must carry the parameter burden. It explains the scope default and its effect ('ALL so date ranges count the archive') and delegates the rest to search_tenders' filter set, which is a useful pointer but not a substitute for documenting keywords, countries, cpv_codes, notice_types, and the published_since/until format.

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 ('count matching notices') and immediately distinguishes it from the listing behavior of its sibling by saying 'without listing them'. The parenthetical '(cheap demand signal)' clarifies the intent behind the tool, so an agent understands both what it does and why it exists versus search_tenders.

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?

Explicitly routes the agent to search_tenders for the filter set ('Same filters as search_tenders') and gives a concrete usage pattern (compare the same filters across two date windows). It lacks an explicit when-not clause (e.g., 'do not use when you need the actual notices'), but the context is clear.

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 readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: fields default to a standard set and unknown fields are rejected by TED, i.e. the query is validated and can fail on bad field names.

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-loads the purpose, then supplies one worked example and two short rules. No filler; the lowercase 'fields:' block is slightly unpolished but every sentence 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?

An output schema exists so return values need not be described, and the example query covers the hardest part of the syntax. However, the scope enum (ACTIVE/LATEST/ALL) governs which notices are searched and is left undefined, which is a material gap for a search tool.

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%, so the description must carry the load. It documents the required 'query' parameter with a concrete syntax example and explains 'fields' (default set, unknown fields rejected), but says nothing about page, limit, scope (ACTIVE/LATEST/ALL) or language, leaving four of six parameters unexplained anywhere.

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 — running a raw TED expert-search query — and the parenthetical '(advanced)' signals this is the low-level escape hatch rather than a structured search. It does not explicitly name search_tenders as the simpler alternative, so sibling differentiation is only implicit.

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?

"Use check_query first if unsure about syntax" gives an explicit routing rule to a named sibling for a specific condition. It stops short of stating when to use this raw query tool instead of search_tenders, which is the more consequential decision.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value with the return shape ('total match count plus normalised notices (title, buyer, country, CPV, value, URL)') and per-param semantics, but says nothing about pagination behavior, rate limits, or how scope=ALL affects volume.

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?

One purpose sentence followed by a compact, front-loaded parameter list where every line adds new syntactic or format information. The structure is scannable; the only minor cost is that the list doubles as documentation for parameters the schema already names.

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?

An output schema exists, yet the description still usefully summarizes the return payload; the filter parameters that drive matching are well covered. The gaps are the unset pagination and language parameters, which an agent may need for multi-page retrieval but which are less critical than the filters.

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%, so the description carries the full burden and mostly succeeds: it explains OR-combining for keywords, ISO alpha-3/alpha-2 for countries, 8-digit CPV format with examples, YYYY-MM-DD dates, and concrete notice_type values. It leaves page, limit, and language undocumented, which keeps it short of a 5.

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 first line states a specific verb and resource ('Search EU public tenders') plus a scope qualifier ('simple filters'), which is clear enough for an agent to act on. However, it never distinguishes itself from siblings like search_notices or count_tenders, so an agent cannot tell which search tool is correct without opening the schemas.

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 phrase 'simple filters' and the scope enum explanations ('ACTIVE (open now), LATEST, or ALL (archive)') implicitly convey when this tool is appropriate, but there is no explicit when-not or alternative routing despite three closely related siblings (search_notices, count_tenders, check_query). Usage is inferable rather than stated.

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