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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on genuinely additive behavior: Blind Mode drops officer/PSC data and address lines in favour of locality/postcode, data refreshes daily, each call costs 1 credit with a key, and keyless use is capped at 5 preview rows and 20 calls/day. These are exactly the operational traits an agent cannot get from the structured fields.

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 tight sentences with the resource and returned fields front-loaded, followed by privacy scoping and then cost. No filler or repeated annotation restatement; the only slight drag is packing Blind Mode, credits, and rate limits into one long sentence.

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 usefully enumerates returned fields and discloses cost/rate limits, which is more than many peers. However, for a 12-parameter tool with zero schema documentation it omits pagination behaviour, sort order, and the semantics of most filters, so an agent still cannot call it precisely beyond q plus AND-combined 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% across 12 parameters, so the description carries the full burden, yet it only explains that filters combine with AND and that q searches all text fields. It says nothing about status or company_type value domains, sic_codes format, company_number vs company, postal_code/locality matching behaviour, or the date bounds — leaving most parameters ambiguous.

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 a specific resource (newest companies on the UK register, sourced from the official Companies House API) and enumerates the returned fields, which cleanly separates it from sibling datasets like query_uk_charities or query_uk_insolvency. It stops short of a 5 because the tool name 'query_uk_companies' implies arbitrary UK company search while the description scopes it to newest incorporations only, and no explicit verb frames the operation.

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 when-to-use guidance and no routing to or away from any sibling tool; an agent is left to infer that this is for browsing recent incorporations rather than querying companies generally. The credit and preview limits are cost context, not usage guidance, and no exclusions or prerequisites are stated.

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