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

Annotations already declare readOnlyHint and openWorldHint, and an output schema exists, yet the description still adds value: it identifies the live external authority, advertises the substantive fields (status, incorporation date, SIC codes, insolvency history, overdue accounts) and the source_url that enables citation. It omits edge-case behavior such as what happens for an unknown or malformed company number, which keeps it below a 5.

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?

Two tight sentences: the lookup definition with example comes first, then the returned fields, then the usage constraint. Every clause carries information and nothing is repeated from the schema or annotations.

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?

Annotations cover the safety profile and the output schema covers return structure, so the description only needs to add selection and input-format guidance, which it does. The one gap is failure behavior for invalid or not-found company numbers, which an agent might reasonably need before committing to a call.

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% — the schema only says 'Company Number' as a bare string — so the description must compensate, and it does by giving the concrete example '00445790', conveying zero-padded numeric format. It does not state whether the leading zeros or any prefix are mandatory, so it falls short of complete semantics.

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 (look up a UK company), names the authoritative source (Companies House), and the lookup key (company number). This is clearly distinct from the sibling tools list_profiles, search_tenders and score_tenders, so an agent can select it without opening the 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?

Explicitly instructs 'Use before stating anything about a company's status; never infer it', which is a concrete when-to-use rule plus a prohibition on guessing. It does not name an alternative tool for the case where the company number is unknown, so it stops just short of full routing guidance.

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=true and openWorldHint=true, so the safety profile is covered. The description adds a hint about result content ("with what each one covers"), but says nothing about ordering, caching, or whether the profile set is fixed — left to the output schema, which exists.

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 sentence with no filler. The core action leads, and the qualifying clause about score_tenders follows immediately, so nothing needs trimming or reordering.

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-parameter, read-only listing tool with an output schema and readOnly annotations, the description covers what it does and why it matters in the score_tenders workflow. The only mild gap is that it does not say what a "profile" contains or whether invoking it has side effects on profiling state.

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?

There are zero parameters, so there is no parameter meaning to convey; the empty schema is self-explanatory. No misdirection about inputs, hence the baseline 4 rather than a 5, which would require the description to add something about input handling.

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 states a specific verb and resource ("List the bid profiles") and immediately ties the resource to the sibling tool that consumes it ("that score_tenders can use"), so an agent can tell it apart from search_tenders and score_tenders 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?

It gives clear usage context: call this to discover the valid profile inputs before/instead of guessing at score_tenders. It stops short of explicit exclusions or step ordering (e.g., "call this first if you don't know a profile id"), so it is strong context rather than a full when/when-not rule set.

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 only declare readOnlyHint and openWorldHint; the description adds real context beyond that — it names the two external corpora searched (Find a Tender and Contracts Finder), the result ordering (GO then MAYBE, highest score first), the hard cap of 50, and the non-obvious behavior that NO-GO results are counted but omitted unless include_no_go is set.

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-loaded with purpose, then trigger, then source/return behavior — a sensible progression with no filler sentences. Slightly dense in the final sentence, where return fields and the NO-GO exception are packed together.

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 enumerating GO/MAYBE fields is a bonus rather than a requirement. However, for a five-parameter, zero-coverage schema the description should account for every input, and `regions` is never mentioned anywhere, leaving an agent unable to use it confidently.

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%, so the description must carry the load. It documents limit's range (1-50), the exact effect of include_no_go, and how to obtain valid profile values, but leaves `regions` completely unexplained and only implies `days` through the phrase "this week's" despite a default of 7.

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 ("Score this week's open tenders") plus the exact output classification (GO / MAYBE / NO-GO against a bid profile, with reasons). The scoring/ranking framing makes it clearly distinct from search_tenders, and it names list_profiles as a dependency.

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 an explicit trigger ("Use when the user asks which tenders are worth bidding for") and a prerequisite workflow step ("Call list_profiles for valid names"). It does not explicitly say when to prefer search_tenders instead, so the exclusion half of the guidance is missing.

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 and openWorldHint, and the description adds real behavior: it queries Find a Tender and Contracts Finder together, de-duplicates notices listed on both, drops expired tenders, and returns results soonest-deadline-first. The main omission is that the `source` parameter can narrow to a single registry, which contradicts the flat claim that it always searches both.

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 compact sentences, front-loaded with scope, then filters, then return shape — no filler. The closing clause listing returned fields is mildly redundant given an output schema exists, but it is short and orients the agent before the call.

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 five-parameter read-only search with an output schema and safety annotations already in place, the description covers scope, filtering, de-duplication, expiry handling, ordering, and result caps. Only the `source` filter and default values are left unstated, which is a small gap relative to everything else it supplies.

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, and it does add value by supplying ranges the schema lacks (`days` 1-30, `limit` 1-50) and by giving a concrete regions example. However, it never explains the `source` enum (all/find_a_tender/contracts_finder) and does not mention that `days` defaults to 7 and `limit` to 20, leaving one of five parameters and all defaults undocumented.

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 ('Find open UK public-sector tenders') plus the freshness window and both underlying sources, so an agent knows exactly what corpus is being queried. It is unmistakably distinct from the sibling tools (list_profiles, get_company, score_tenders), which operate on different objects.

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 context for when this applies: open tenders only, published or updated within `days`, with expired deadlines dropped. It marks keywords and regions as optional filters, but never states when to prefer this over score_tenders or what to do if zero results come back.

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