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

With no annotations, the description carries the full behavioral burden, and it does disclose several non-obvious traits: the hard cap of 50 companies, the required 8-character number format, and the partial-failure contract ('Unknown numbers come back with found=false'). It omits whether the call is read-only, any rate limits, credit costs, or result ordering, which keeps it out of the top band.

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 short sentences with zero filler, front-loaded with the action and batch scope, followed by the input format and the edge-case behavior. Every sentence 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?

There is no output schema and no annotations, so the description has to carry return-value and safety context. Listing the returned fields effectively substitutes for an output schema, and the found=false contract covers the main edge case; missing details are result ordering and read-only/permission expectations.

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 single parameter has only a title ('Company Numbers'), so the description must compensate. It does so by specifying that the argument is a list of 8-character company numbers and by defining the not-found outcome per entry, adding real meaning beyond the bare array-of-strings schema.

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 gives a concrete verb ('Enrich') plus resource ('UK companies') and enumerates the exact fields returned (status, R-Score, overdue flags, charges, CCJs, net assets, credit exposure). The batch scope ('in one call', 'up to 50') implicitly distinguishes it from the single-company sibling get_company, but no sibling is named explicitly, so it falls short of a 5.

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?

Usage is implied rather than stated: 'up to 50 ... in one call' signals this is the bulk alternative to per-company lookups, and the required input format is given. There is no explicit when-to-use guidance, no statement of when to prefer get_company or search_companies instead, and no prerequisites.

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?

With no annotations, the description carries the full disclosure burden. It usefully discloses the coverage restriction (SC/NI/OC prefixes unsupported), which is a real behavioral constraint, but says nothing about read-only nature, credit/cost consumption (a 'usage' sibling hints at metering), or latency for such a data-heavy response.

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, front-loaded sentences: what you get, how to identify the company, and the coverage caveat. The enumerated payload earns its length because no output schema exists to communicate return values.

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 and no annotations, the description does the work of describing return contents and input format, and flags the geographic limitation. What is missing is minor: no mention of cost/credits per call, and no fallback guidance when the company is outside England & Wales.

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 parameter is completely undocumented in structured form; the description compensates by specifying the 8-character Companies House format and giving a concrete example (04466987), plus the prefix restriction. Strong for a single parameter.

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 ('Full credit profile of a UK company') and enumerates the concrete payload: R-Score, risk band, five years of financials, filings, charges, CCJs, directors, alerts, exposure, and narrative. This also implicitly distinguishes it from get_risk_narrative (a subset) and search_companies (the finder).

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?

Usage is only implied: the description makes clear this is a single-company profile lookup given a company number, and it excludes non-England & Wales entities. It never explicitly says when to prefer this over get_risk_narrative or that search_companies should be used first to obtain a number.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the separate metering/billing trait and the validation state of the data, but says nothing about permissions, failure behavior for non-UK companies, or rate limits beyond cost.

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 sentences, front-loaded with the returned content and then the cost warning. The em-dash clause is slightly loose but every clause carries information; nothing is wasted.

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?

No output schema and no annotations, so the description is the only source of shape information. It lists what comes back but not the structure of the returned payload (single vs list of emails/phones), which is a notable gap for a tool whose output is the whole point.

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% for the single required parameter, so the description must compensate. It adds the useful framing that the identifier is a UK company number, but does not state the format (e.g. Companies House 8-character number), leaving the schema to carry the rest.

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 (contact details for a UK company) and enumerates the returned fields — SMTP-validated emails, phone, website domain. That distinguishes it from search_companies and get_company, though it does not name a sibling explicitly.

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 a clear usage condition: metered separately, use sparingly, only when the user actually needs contact details. That is a real when-to-use rule, but it never names the cheaper alternative (get_company) that an agent should prefer for general company data.

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?

With no annotations, the description carries the full burden and does disclose meaningful traits: no external credit fetch (data sourcing), cheapest/fastest (cost and latency), and plain-English output (response style). It stops short of stating failure modes, auth needs, or the exact return shape.

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 short sentences, front-loaded with the artifact and its defining constraint, then the usage condition. No filler beyond a small amount of cost framing that itself carries selection value.

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 simple one-parameter lookup with no annotations and no output schema, the description covers purpose, when-to-use, data sourcing, cost, and output style. Only the parameter format and any failure/empty-result behavior are left unspecified.

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 single parameter is required, so the description must compensate. 'For a UK company' hints that company_number is a UK registration identifier but gives no format, length, or validation guidance, so it only partially fills the gap.

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 artifact (plain-English risk summary) and its scope (a UK company), and implicitly contrasts it with the 'full profile' tool, so an agent can tell it apart from get_company without opening either schema. It also defines what 'narrative' means, which the name alone does not.

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 condition: 'Use when the user just wants is this company safe to deal with rather than the full profile.' It names the alternative (full profile) and the intent that selects this tool instead, plus the cost/effort tradeoff ('cheapest call').

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?

With no annotations, the description carries the full burden and does disclose the result cap (up to 20 matches) and the returned fields (company_number, name, status, R-Score). It omits matching behavior (exact vs. fuzzy) and any auth or rate-limit considerations, so it is good but not exhaustive.

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 short sentences, each earning its place: what it does, when to reach for it, and what comes back. The routing guidance is front-loaded immediately after the purpose.

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 and no annotations, the description usefully covers the return fields and the 20-match cap. It stops short of explaining name-matching behavior or what happens when more than 20 companies match, which an agent would want to know.

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 meaning. "Search UK companies by name" establishes that query is a company name, but it adds no detail on matching semantics, minimum length, or formatting, leaving a gap for a single required parameter.

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 (Search) and resource (UK companies) plus the goal of retrieving a Companies House number. This cleanly separates it from get_company, which takes a number rather than a name.

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 this first when the user gives a company name instead of a number" gives an explicit trigger condition and implies the number-based alternative without naming get_company. No exclusions or edge cases (e.g., ambiguous or partial names) are given, so it falls short of a full 5.

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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the rolling-24h window, that it is scoped to the calling key, and the three counters returned. It is implicitly read-only ('Show') and safe, but it never says whether the numbers are eventually consistent or how the limit is enforced.

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 sentences, no filler: the first states what is returned and over what window, the second states when to call it. The most decision-relevant content is front-loaded and 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?

With no output schema, the description must describe the return payload, and it does by naming the three counters. Combined with explicit invocation triggers and the rolling-24h window, an agent has everything needed to call it correctly and interpret the result.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. The description correctly implies that scope comes from the calling API key rather than from arguments.

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 gives a specific verb and resource: it shows 'this API key's rolling-24h usage against its limits' and enumerates the returned metrics (calls made, calls allowed, contact lookups used). That is far more concrete than the bare name 'usage', though it never explicitly contrasts itself with siblings like batch_enrich, which it implicitly serves.

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 two concrete trigger conditions: call it 'when you hit a rate-limit error or before a large batch.' This tells the agent exactly when to reach for it, and no sibling tool offers this capability, so no alternatives need naming. No exclusions are stated, but none are meaningful for a no-argument status read.

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