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

Annotations already declare readOnly, non-destructive, and idempotent. The description adds meaningful behavioral context about what data to expect (trustees, income/expenditure, insolvency flags) and that it returns a 'full' profile. This goes beyond the annotations without contradicting them.

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 core action, and no filler. The second sentence efficiently lists return contents. Every word 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?

Given the simple one-parameter schema and availability of an output schema, the description covers the essential context: what it fetches, what it returns, and the prerequisite step. No significant gaps remain.

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 100% and the parameter description already explains the format and origin ('Returned by charity_search'). The tool description reinforces the usage but doesn't add new meaning beyond the schema beyond implying the parameter is central to the lookup.

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 uses the specific verb 'Fetch' with a clear resource ('full Charity Commission profile') and the input parameter ('charity number'). It lists concrete data fields returned (trustees, income/expenditure, insolvency flags, etc.), which distinguishes this from sibling tools like charity_search or company_profile.

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 to use charity_search first to obtain the charity number, which is a clear prerequisite and aligns with the sibling tool. This tells the agent when to use this tool versus the search alternative.

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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses non-obvious upstream behavior: the endpoint returns the full list in one shot, pagination is applied client-side via offset/limit, and an upstream HTTP 404 is translated into an empty result rather than a failure. This gives the agent valuable operational context.

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?

The description is front-loaded with the core purpose and then adds only high-value details: the sibling alternative, pagination behavior, and empty-result semantics. Each sentence earns its place without repetition or filler.

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?

Given the output schema exists, return values don't need elaboration. The description covers the search scope, alternative tool, pagination mechanics, and error semantics, making it fully sufficient for an agent to call this tool correctly without further ambiguity.

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 input schema already describes all three parameters (query, limit, offset) with full coverage, so the description adds no new parameter detail. The mention of client-side pagination indirectly supports offset/limit semantics, but it doesn't expand beyond what the schema already states; baseline 3 is appropriate.

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 ('Search'), a clear resource (the Charity Commission register of England and Wales), and the input mode ('by name or keyword'). It also distinguishes itself from 'charity_profile' by noting the latter is for full details after obtaining the charity number, making sibling differentiation explicit.

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 description explicitly tells the agent to use 'charity_profile' for full details once the charity number is known, providing a clear alternative and the condition for choosing it. It also clarifies the empty-result behavior, so the agent knows how to interpret a no-match response versus an error.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail about what a charge record includes and the specific representation of satisfaction (satisfied_on plus a filing, not a separate release). It also notes the source of company_profile.has_charges, which helps the agent understand the data relationship.

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?

The description is well-structured and front-loaded with the core purpose. The second sentence adds useful detail about response contents, and the final sentence provides selection guidance. A small redundancy exists between 'complete charge history' and 'Returns every registered charge', but overall the text is efficient and every sentence contributes meaningful context.

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 single-parameter fetch tool, the description fully explains what the tool returns, how to distinguish it from the summary field, and how an important edge case (satisfaction) is represented. The output schema exists to describe the response structure, so the description does not need to enumerate all fields. The combination of description, schema, and annotations provides everything an agent needs to invoke this correctly.

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 is only one parameter and the schema description coverage is 100%, fully documenting company_number with format and an example. The description does not add new parameter semantics beyond the schema, which is acceptable given the high coverage. The baseline of 3 applies because the schema carries the burden successfully.

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 clearly states it fetches the complete Companies House charge history for a company. It explicitly contrasts with company_profile.has_charges, noting this tool should be used when specific charges matter. This differentiates it from sibling tools without needing to inspect other 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 description gives explicit guidance on when to use this tool versus company_profile.has_charges: use this when the actual charge details matter, not just whether any charges exist. It also clarifies how satisfaction is represented, preventing misinterpretation. This is strong usage context that helps an agent select correctly.

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?

Beyond the readOnlyHint annotation, the description discloses that no bytes are ever embedded or base64-encoded, that only metadata is read, that the tool never downloads the document, and that a resource-capable client is required for actual content. This gives the agent accurate expectations about side effects and outputs.

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?

The description is well-structured and front-loaded, but slightly verbose with some repetition around the client requirement and the fact that no bytes are downloaded. Each sentence earns its place, yet it could be tightened without losing meaning.

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?

Given two parameters, no output schema, and a read-only idempotent operation, the description covers what is returned, how to access the actual PDF, what metadata is available, prerequisites, and client limitations. An agent has enough context to invoke the tool correctly and interpret results.

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 100%, so the schema already documents both parameters well. The description reinforces key constraints like passing the URL verbatim and the mime_type auto-selection behavior, but adds little beyond the schema's own parameter descriptions.

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 uses a specific verb ('Resolve') and identifies the exact resource (a filing's document_metadata link), then clarifies the output is a resource_link, not bytes. This clearly distinguishes it from sibling tools like fetch or company_filing_history, which the description explicitly references as the prerequisite step.

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 description gives explicit usage direction: first use company_filing_history to obtain the document_metadata_url, then call this tool, and retrieve the actual PDF via resources/read. It also states the limitation for tool-only clients, so an agent knows when this tool alone is insufficient.

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?

The description richly discloses behaviors beyond the annotations: it fetches exactly one page, never silently truncates, reports total_count/returned/has_more truthfully, returns raw source data rather than interpreted conclusions, and distinguishes a structured not_found error from an empty result. These details are not covered by the readOnly/openWorld/idempotent hints, so the description carries crucial execution context.

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?

The description is longer than average, but every sentence earns its place: purpose, pagination contract, category narrowing, raw-data caveat, and not_found handling. The key limitation ('does NOT auto-fetch every page') is front-loaded, and the not_found discussion is substantive rather than filler.

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?

The description covers all critical operational dimensions: pagination contract, category filtering, raw vs interpreted data, document identifier purpose, and error handling for unknown company numbers. With an output schema present, return values don't need to be spelled out, and no essential behavior an agent would need to call this tool correctly is missing.

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?

All four parameters are already fully documented in the schema with descriptions, defaults, and enumeration examples (100% coverage), so the baseline of 3 applies. The description adds contextual value by mentioning category='mortgage'/'insolvency' and the pagination idiom, but it doesn't reveal new parameter semantics beyond what the schema already states.

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 opens with a specific verb and resource: 'Fetch one page of a company's Companies House filing chronology.' It immediately distinguishes this tool from siblings by emphasizing raw source facts, one-page pagination, and the absence of document-content fetching, so an agent can easily tell it apart.

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 description explicitly contrasts with company_officers/company_psc/company_charges on auto-fetching and states that no document content is fetched, signaling when this tool is not appropriate. It also advises pagination via start_index while has_more is true and narrowing with category= for specific slices. It doesn't name company_filing_document as the document-retrieval alternative, but the mention of a future document-retrieval tool makes the boundary fairly 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds genuine behavioral context beyond the annotations: the default exclusion of resigned officers, the flag to include them for historical due diligence, and the fact that pagination is handled internally. These are meaningful traits not inferable from the schema or annotations 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?

The description is three concise sentences with no filler: it leads with the core purpose, lists returned data, and then covers the important defaults and pagination 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?

For a read-only list tool with an output schema, full parameter documentation, and safety annotations, the description covers all necessary operational details: scope, returned fields, default behavior, the optional flag, and pagination. Nothing that an agent needs to call it correctly is missing.

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 100%, so the baseline is 3. The description adds value by explaining that pagination is handled internally, which clarifies why start_index and items_per_page are ignored, and by stating the default behavior of include_resigned. This goes beyond the parameter descriptions.

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 ('Fetch officers for a Companies House company number') and enumerates the officer types and returned fields. It clearly distinguishes the tool's function, though it does not explicitly contrast it with sibling tools like officer_appointments or company_profile.

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 description gives clear invocation context: what data is returned, that resigned officers are excluded by default, and when to set include_resigned=true for historical data. It does not explicitly name alternative tools or when not to use this one, but the scope is specific enough for an agent to select it appropriately.

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 cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral context by specifying what the profile includes, such as overdue accounts, confirmation statement flags, and outstanding charges. No contradiction exists between the description and annotations.

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: purpose, return contents, and prerequisite workflow. Every sentence adds value, and the most important information is front-loaded. No filler or redundant restatement of the tool name.

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?

The single parameter is fully documented in the schema, output schema exists so return values are defined elsewhere, annotations cover the safety profile, and the description provides scope and a prerequisite. Nothing critical is missing for an agent to invoke the tool correctly.

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 input schema already documents company_number with length constraints, format example, and a pointer to company_search. The description reinforces that the tool is called with a company number but adds little beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.

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: 'Fetch the full Companies House profile for a company number.' It also lists the returned data (status, registered address, SIC codes, filing compliance, outstanding charges), which clearly distinguishes it from sibling tools like company_search, company_officers, and company_psc.

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 description gives explicit workflow guidance: 'Use company_search first to find the company number.' This is clear and actionable, though it doesn't explicitly state when not to use this tool in favor of other siblings like company_officers or company_charges.

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 indicate read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral detail by explaining that overseas corporate PSC entries are flagged as a risk signal and that widely-held PLCs with no registrable PSC receive an explanatory note.

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?

The description is three sentences with no filler. It front-loads the core purpose and then efficiently covers key output details and a special-case behavior, earning its length.

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 read-only lookup with one documented parameter and an output schema, the description covers purpose, key result fields, risk flagging behavior, and an important edge case. Nothing essential is missing for an agent to invoke it correctly.

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 100% and the single parameter is already well described with format guidance and an example in the schema. The description does not add additional parameter-level detail, so the baseline score of 3 is appropriate.

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 uses a specific verb ('Fetch') with a clear resource ('Persons with Significant Control') and adds 'beneficial ownership' for disambiguation. It clearly distinguishes itself from sibling tools like company_officers and company_profile by focusing on PSC data specifically.

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 description makes it clear this tool is for retrieving PSC/beneficial ownership information for a company, which gives strong contextual guidance. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough that an agent can infer when to use it.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral details beyond annotations: it returns a paginated list with specific fields (name, number, status, SIC codes, incorporation date, registered address) and explains the pagination mechanism, which is valuable, non-obvious context.

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?

The description is three sentences, each earning its place: purpose, return behavior, and referral/pagination guidance. It is front-loaded and free of redundancy.

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?

Given the tool's search nature, the description covers essential aspects: what it searches, what it returns, how pagination works, and when to use a sibling tool (company_profile). The output schema presumably handles return structure details, so the description is complete.

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 100%, so baseline is 3. The description enriches this by clarifying 'query' as company name or keyword and by explicitly stating the pagination formula (start_index=start_index+items_per_page), which adds meaning beyond the schema's individual parameter descriptions.

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 clearly states it searches the Companies House register by company name or keyword, with a specific verb and resource. It also distinguishes itself from company_profile by explicitly directing users there for full records, making its scope 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?

The description explicitly names an alternative (company_profile) and provides an exclusion ('Use company_profile for the full record once you have the company number'). It also gives concrete pagination instructions (re-call with start_index+items_per_page), giving clear when-to-use 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 the operation read-only, idempotent, and non-destructive. The description adds the return contents (reasons, Act/section, period, company names) and reinforces the need for a pre-discovered officer ID, which is valuable context beyond the annotations.

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?

The description is two sentences: a clear action statement and a compact list of returns plus usage note. Every phrase contributes value with no redundancy.

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?

Given a single parameter with 100% schema coverage and an output schema present, the description fully captures the tool's purpose, prerequisites, and return contents. It is sufficiently complete for an agent to invoke correctly.

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 schema already covers officer_id with a full description including its source. The description repeats this linkage but does not introduce new parameter constraints or types, so the baseline of 3 is appropriate.

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 clearly identifies the action ('Fetch') and the resource ('full disqualification record for a director') via officer ID. It distinguishes itself from the sibling disqualified_search by focusing on retrieval of a specific record rather than searching.

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 explicitly states the prerequisite workflow: 'Use disqualified_search first to find the officer ID.' This provides clear guidance on when to use this tool and points to the alternative tool for discovery.

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 establish read-only, idempotent, non-destructive behavior. The description adds key behavioral context beyond that: the company name query returns zero results (a known pitfall), and it reveals the return shape (names, DOBs, snippets, officer IDs) plus a pointer to disqualified_profile for follow-up. This exceeds the annotation baseline without being exhaustive about rate limits or matching nuances.

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?

Four sentences, each earning its place: purpose, when-to-use, critical restriction, and return value summary. Front-loaded with the most important info, no redundancy or fluff. Perfectly sized for quick parsing by an agent.

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?

The tool is simple, has an output schema, and annotations cover safety. The description covers purpose, usage guidelines, a key anti-pattern, and a related-tool pointer. Pagination and limits are already captured in the schema, so nothing critical is missing. The context is complete for reliable invocation.

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 100%: each parameter has a meaningful description, including the alias relationship between 'name' and 'query' and clarifying 'NOT a company name.' The tool description reinforces this but doesn't introduce new parameter-level semantics. Baseline 3 is appropriate because the schema carries the burden.

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 opens with a specific verb+resource: 'Check whether a named individual is banned from acting as a UK company director.' This clearly distinguishes the tool from siblings like company_search (which searches companies) and disqualified_profile (which retrieves full details for an identified officer). The scope is precise and 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?

Provides explicit when-to-use guidance: 'Use this tool when asked to check disqualified, banned, or barred directors.' It also warns against a common mistake: 'Query must be an individual's name — NOT a company name, which always returns zero results.' This exclusion is valuable and no other tool is suggested for this purpose, making the guidance direct and actionable.

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 cover the read-only, idempotent, and non-destructive nature, so the bar is lower. The description adds useful behavioral context by explaining how the tool routes by prefix to the appropriate register, which is beyond the annotations. No contradictions.

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?

The description is succinct: a one-sentence purpose followed by a bulleted list of routing rules. Every sentence is informative, there is no unnecessary text, and the structure is front-loaded and scannable.

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 single-parameter tool with an output schema and read-only annotations, the description covers all essential context: what it does, when to use it, and how routing works. It doesn't need to explain return values because the output schema exists, and the usage context is clear.

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 schema covers the parameter format 100%, so the baseline is 3. The description adds value by mapping each prefix to its target register, enriching the semantics beyond the schema's format description. This helps the agent construct valid IDs and anticipate the output type.

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 clearly states the verb and resource: 'Fetch the full record for an ID returned by search.' It distinguishes from sibling tools by specifying the routing mechanism by prefix, which clarifies that this is a unified fetcher across multiple registers. This is specific and 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?

The description gives a clear context: use this for IDs returned by search. It implicitly differentiates from specific profile tools via the prefix routing, but it does not explicitly state alternatives like 'use company_profile if you already have a company number.' A slight gap in explicit exclusion 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?

The description adds meaningful behavioral context beyond the annotations: results are sorted by an internal DD severity score, the notice label is preserved as a source fact, and a published notice is legally effective. These details are not visible in the annotations and help an agent interpret results and avoid assuming chronological ordering.

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?

The description is well-structured and mostly front-loaded, but the first two sentences both announce the same search operation with slightly different phrasing. Every other sentence earns its place by explaining sorting, result IDs, or the legal significance of a Gazette notice.

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?

The description covers the key non-obvious behaviors an agent needs: the insolvency-specific scope, severity-based sorting, the presence of notice_numeric_id, the separate notice resource for full wording, and the legal effectiveness of published notices. Given that an output schema exists and the parameter schema is fully documented, nothing critical appears missing.

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 input schema already provides 100% coverage of parameter meanings, including aliases, date formats, max_notices caps, and notice_type examples. The description adds some useful context around the notice-code taxonomy and the result's numeric ID, but it does not materially improve parameter-level understanding beyond the 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 names a specific verb ('Search') and a specific resource ('The Gazette's corporate-insolvency notice index'), and also indicates the search is by entity name. It differentiates this tool from siblings like gazette_notice by noting results contain a notice_numeric_id and that the full legal wording is available separately via a notice:// resource.

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 description clearly frames this as the entry point for finding insolvency notices and then directs the user to read the full legal wording via notice://{notice_numeric_id}, which functions as an implicit alternative path. It does not explicitly state 'use gazette_notice for full notices' or list exclusions, but the context is clear enough for an agent to choose correctly.

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?

Beyond the readOnly and idempotent annotations, the description adds that the response is a complete JSON-LD record including parties, legal basis, court, and full text. It does not mention error handling or potential limits, but the key behavioral traits are well covered.

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 efficiently deliver purpose, return contents, and a usage prerequisite. The structure is front-loaded with the action and avoids any redundant phrasing.

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?

Despite having an output schema, the description provides a succinct summary of return fields and gives the necessary upstream step. For a single-parameter fetch operation, this is complete and well-integrated with sibling tools.

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 schema already fully describes notice_id as the numeric ID returned by gazette_insolvency, and the description echoes this without adding new meaning. With 100% schema coverage, the baseline of 3 is appropriate.

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 clearly states it fetches the full legal wording of a Gazette notice by numeric notice ID, distinguishing it from search-like siblings such as gazette_insolvency. The verb 'Fetch' and specific resource make the purpose 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?

It explicitly instructs users to use gazette_insolvency first to obtain notice_numeric_id values, providing a clear workflow and implicit alternative. This is direct guidance on when to use this tool versus another.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context beyond these: it returns a maximum of 10 transactions, lists the exact data fields, restricts to England and Wales, and explains automatic postcode extraction from addresses. This is useful operational detail not present in the annotations.

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 sentences, front-loaded with the main action, followed by return details and key constraints. No filler or redundancy. Every sentence contributes meaningful guidance, making this highly concise and well-structured.

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 single-parameter tool with a provided output schema, the description is complete: it states the data source, coverage area, reliability guidance, and expected return fields/count. There's no ambiguity that would require additional narrative. The output schema covers structural details, so the description's brevity is appropriate.

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 single parameter 'address_or_postcode' is already described in the schema with the same guidance (postcode most reliable, full address accepted). The description adds a small extra detail about automatic postcode extraction, but with 100% schema coverage, the schema carries the semantic weight. Per the rubric, baseline 3 is appropriate.

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 opens with a specific verb+resource: 'Search HM Land Registry Price Paid Index by postcode or address.' It clearly distinguishes this tool from sibling tools by focusing on property transaction data, and states the return content (price, date, address, property type, tenure). This leaves no ambiguity about what the tool does.

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 contextual guidance: covers England and Wales only, postcode is most reliable, full address accepted with automatic postcode extraction. It doesn't explicitly name alternatives or exclusion conditions, but the guidance is sufficient for choosing this tool for price paid lookups. Score 4 rather than 5 because there's no explicit 'when not to use' statement.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond that: it returns current and historic appointments, includes dissolved or insolvent companies, and explicitly discloses that there is no current-only filter. No contradiction with annotations.

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?

The description is front-loaded with the core purpose, followed by return details, the prerequisite workflow, and an explicit limitation. Every sentence adds decision-relevant information and there is no filler or repetition.

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 a single parameter, a strong output schema, and annotations covering safety and idempotency, the description fills the remaining gaps: what data is returned, how to obtain the required officer_id, and what filtering behavior to expect. Nothing essential is missing for correct invocation.

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 100%, and the schema already explains officer_id as a Companies House officer ID returned by company_officers. The description adds a little context by saying the officer ID is used to fetch appointment history, but it does not materially expand on the schema. This meets the baseline for high schema coverage.

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 starts with a specific verb and resource: 'Fetch a person's full company appointment history by officer ID.' It clearly distinguishes itself from the sibling company_officers tool by emphasizing historical appointment discovery across companies, not just a company's current officers.

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 description gives an explicit workflow: use company_officers first to find an officer_id, then use this tool. It also states the tool always returns full history and has no current-only filter, which prevents misuse when a current-only view is needed.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing deterministic matching semantics, the risk of transliteration variants, false positives on common names, and that empty results are not clearance. It also explains partial-failure behaviour (`is_partial`, `lists_unavailable`, retryable error when no list loads) — exactly the kind of context annotations cannot express.

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?

The description is long, but it is well front-loaded (purpose first, then matching semantics, then failure modes) and every paragraph carries non-redundant information. Slightly dense, though nothing reads as filler.

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?

Given a screening tool with failure modes and an output schema, the description covers matching behaviour, partial-list semantics, error behaviour, and the meaning of `as_at`. An agent has everything needed to interpret results safely.

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 100%, so the schema already documents both `name` and `entity_type`. The description adds matching semantics around the name but never addresses the `entity_type` filter, so it stays at the baseline.

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 (screen), resource (a name), and the exact data sources (UK OFSI, US OFAC, EU, UN consolidated lists). This is clearly distinguishable from all siblings such as company_profile, disqualified_search, and company_search.

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 concrete usage context: check whether a counterparty, or its officers/PSC, appears on a sanctions list. It describes the purpose clearly but does not name an alternative tool or an explicit when-not-to-use condition.

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?

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the parallel execution model, the ID-only return shape, and the partial-failure semantics: `registers_searched` vs `registers_unavailable` with `is_partial`, the critical warning that empty ids + is_partial=true means UNRESOLVED rather than 'nothing on record', and that a total register outage raises instead of returning empty.

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 sentence, then layers scope, retrieval workflow, and failure semantics in tight, well-organized sentences. Every sentence carries distinct, actionable information with no filler.

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?

Despite an output schema existing, the description usefully clarifies the return contract (result IDs plus fetch workflow) and fully specifies the partial-vs-unresolved failure distinction. Nothing an agent needs to interpret results or handle degraded register responses is missing.

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?

With a single parameter at 100% schema coverage, the schema already documents that `query` accepts a company name, charity name, director name, or keyword. The description adds no format, syntax, or length guidance beyond what the schema provides, so the baseline 3 applies.

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 (all UK due diligence registers), enumerating the exact registers covered: Companies House, Charity Commission, disqualified directors, and Gazette insolvency notices. This aggregate scope cleanly distinguishes it from per-register siblings like company_search, charity_search, and disqualified_search.

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?

Clearly establishes the aggregate use case ('search across all registers simultaneously') and the required follow-up workflow: results are IDs, so 'use fetch with each ID to retrieve the full record.' It does not explicitly state when to prefer a narrower sibling (e.g. company_search) over this one, so it stops short of full alternative routing.

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