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

With no annotations provided, the description carries the full burden and delivers: the two-week rolling window, daily refresh, the flattened one-row-per-award-and-supplier data model, the organisation-level restriction, AND-combination of filters, q semantics, and the 1-credit cost. These are genuine behavioral traits an agent cannot infer from the schema alone.

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?

Information-dense with no filler — the purpose is front-loaded as a question, followed by source, fields, temporal window, exclusions, filter semantics, and cost. The first sentence is somewhat sprawling with the dash construction and long field list, but every clause earns 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 15-parameter tool with no annotations and no output schema, the description covers purpose, source, freshness window, data granularity, filter composition, q behavior, and credit cost. What an agent still lacks is the expected date format for the four date parameters and confirmation of pagination behavior, which are material gaps for constructing correct calls.

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 0% with 15 undocumented parameters, so the description must compensate. It maps most content-bearing parameters (buyer, supplier, supplier_company_number, award_value_amount, award_date, cpv_codes, category, procurement_method) by listing the data fields, and explains q's behavior and AND-combination. Gaps remain: date formats, published_at_after/before semantics, and page/per_page behavior are not described.

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 opening question 'Who won which UK public-sector contract, for how much' is a specific verb+resource statement, and 'award notices from the official Contracts Finder OCDS feed' names the exact data source. It differentiates from siblings by using 'award notices' versus query_uk_tenders (tenders) and by scoping to the UK Contracts Finder feed versus query_eu_ted.

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 clear usage context: 'Rolling window of the last two weeks of awards, refreshed daily' tells when the data is current, 'Organisation-level data only' is an explicit exclusion, and 'Filters combine with AND; q searches all text fields' prescribes how to compose queries. However, it never names alternatives like query_uk_tenders or query_eu_ted, so routing between siblings is left implied.

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