UK Due Diligence

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?

Annotations already mark it read-only and idempotent, but the description adds valuable behavioral detail: the upstream endpoint returns a full list in one shot, pagination is client-side, and an upstream HTTP 404 is translated into a successful empty result rather than an error. This meaningfully changes how the agent should interpret responses.

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?

Every sentence delivers distinct value: scope, returned fields, sibling routing, pagination behavior, and empty-result semantics. There is no filler, no redundancy with the schema, and the key purpose is front-loaded.

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 an output schema, full parameter documentation, and strong safety hints in annotations, the description covers all practical gaps an agent needs: geographical scope, response fields, navigation to charity_profile, pagination semantics, and error translation behavior.

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 parameters clearly, but the description adds important deeper context: offset/limit apply client-side because the upstream endpoint returns everything at once. This helps an agent understand the mechanics of pagination beyond the raw schema definitions.

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 explicitly names the action ('Search'), the resource ('Charity Commission register of England and Wales'), and the scope ('by name or keyword'). It also distinguishes itself from the charity_profile sibling by describing search-level results versus full details.

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 direction: use this tool to search and find charity numbers, then 'Use charity_profile for full details once you have the charity number.' This effectively states when to use this tool versus its nearest 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?

Annotations already establish the tool as read-only, idempotent, and non-destructive, so the description adds genuinely useful semantics: satisfaction is represented as satisfied_on plus a charge-satisfaction filing rather than a separate release record. It also explains the relationship to company_profile.has_charges. It stops short of discussing possible pagination or absence-of-result behavior, but these are minor given the rest.

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, each of which earns its place: scope, return semantics, and usage guidance. The description is front-loaded with the main action and resource, and contains 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 description gives the full behavioral contract for the tool: what data is returned, how satisfaction is encoded, and when an agent should prefer this over the related company_profile summary. With a full input schema, strong annotations, and an output schema present, nothing essential is missing for selecting and invoking 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?

Schema coverage is 100% and there is a single parameter, company_number, whose description covers the 8-digit format and where to obtain it from company_search. The tool description adds no additional parameter detail, so the baseline schema-only value 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?

Description leads with a specific verb 'Fetch' and a well-defined resource, 'the complete Companies House charge history for a company.' It enumerates the returned charge fields and states that charges include both current and historic entries, so there is 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?

Explicitly contrasts itself with company_profile.has_charges, a summary field for whether any charges exist, and says to use this tool 'when the specific charges matter, not just whether any exist.' That gives an agent a clear decision rule for selecting this over the relevant sibling tool.

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, destructiveHint), the description explicitly discloses what never happens: no embedded bytes, no base64, no download of the PDF, and no direct retrieval of file bytes. It also clarifies that the tool reads only document metadata, which aligns with and enriches the annotation-provided safety profile.

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 slightly verbose but every sentence carries useful information, including the result format, metadata scope, prerequisite, and client constraint. It is front-loaded with the core action and return type, and the structured formatting makes the tripartite behavior easy to process.

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?

Without an output schema, the description fully compensates by explaining the returned resource_link, the way to fetch the PDF via resources/read, the metadata contents, and the prerequisite call to company_filing_history. It also covers environment constraints, making the tool call meaningfully complete for an AI agent.

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 both parameters thoroughly, including the exact URL format, pass-through requirement, and mime_type auto-selection behavior. The description adds little semantic information beyond repeating these instructions, so baseline 3 is appropriate given the 100% 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 names the specific verb 'Resolve' and the exact resource (a filing's document_metadata link), and states precisely what is returned: a resource_link to a company-document:// MCP resource. It also frames the tool's scope against company_filing_history, making the tool distinct from its siblings.

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 says 'Use company_filing_history first to find a filing's document_metadata URL', giving a clear prerequisite and sequencing instruction. It also explains the client requirement and notes the limitation for tool-only clients, helping an agent decide whether this tool is suitable for the current environment.

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 (readOnly, idempotent, non-destructive), the description richly discloses semantics: it returns raw upstream facts rather than interpreted DD conclusions, enforces single-page semantics, reports pagination fields truthfully, and never silently truncates. It also narrates the structured not_found error distinction—valuable operational detail not evident from 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 essential purpose, then layers nuance: raw facts, pagination behavior, category filtering, and error semantics. It is longer than one-liners, but every sentence carries operational value for an agent deciding whether to invoke the tool and how to interpret its result.

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 complexity, a rich output schema is already present, and the description covers what the agent cannot easily infer: the unbounded pagination problem, the distinction between empty results and not_found, truthful pagination counters, and the non-retrieval of document content. It is complete enough to support correct invocation and interpretation.

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 parameters are already well-documented in the input schema. The description does not systematically add per-parameter semantics, but it adds meaningful usage context such as why category filtering matters (unbounded histories) and how pagination fields behave (start_index=start_index+returned while has_more). That lifts it to the correct baseline but not above.

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 ('Fetch') and resource ('one page ... Companies House filing chronology'), accurately reflecting the tool's scope as paginated/chronological rather than exhaustive. It simultaneously differentiates from sibling tools like company_officers, company_psc, and company_charges by noting the no-auto-fetch behavior, making it easy for an agent to select this tool without opening 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?

It explicitly contrasts this tool with company_officers/company_psc/company_charges, states when pagination is required rather than auto-fetched, and advises narrowly using category= for large histories. It also tells the agent that document content is not retrieved and points to links.document_metadata as a future identifier, providing clear when-to-use/when-not-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?

The annotations already communicate read-only, idempotent, safe behavior. The description adds meaningful context beyond that: resigned officers are excluded by default, include_resigned=true opts into historical data, and pagination is handled internally.

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 short, front-loaded with the core purpose, and every sentence adds information. It covers behavior, output content, and the key parameter option without verbosity.

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 rich schema, output schema, and annotation coverage, the description completes the picture with the important defaults and automatic pagination. A caller has enough context 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 description coverage is 100%, so the parameters are already well documented. The description adds useful framing around include_resigned and pagination, reinforcing the schema without introducing ambiguity.

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 action and resource: 'Fetch officers for a Companies House company number.' It also names the officer categories returned, which distinguishes this from sibling tools like company_profile or company_charges.

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 usage context: who is returned by default, how to include resigned officers, and that pagination is automatic. It does not explicitly name an alternative tool, but handles the main operational decisions a caller needs to make.

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, so the safety profile is covered. The description adds what data will be returned and note of compliance and charge flags, which is useful. It does not discuss rate limits, pagination, or response shape, but the output schema covers some of that burden.

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 short, front-loaded with action and scope, and every sentence serves a purpose: main function, expected contents, and prerequisite step. There is no filler or unnecessary 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?

For a single-parameter read-only tool with an output schema and fully documented input, the description is complete: it explains what the agent will get, why it might want this endpoint, and how to obtain the required company number. Nothing stands out as 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?

The input schema fully documents the only parameter: company_number includes format, max length, an example, and a pointer to company_search. The description reinforces the prerequisite but adds no meaning beyond what the schema already provides, 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 uses a specific verb ('Fetch') and resource ('full Companies House profile'), and makes the scope concrete by enumerating the included data (status, address, SIC codes, compliance flags, charges). This clearly distinguishes it from the sibling tools focused on search, filings, officers, or charges.

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 company_search first to find the company number,' which is a clear precondition and usage cue. It does not explicitly contrast with the alternative company-specific endpoints (e.g., company_filing_history, company_charges), so it is clear but not fully exclusionary.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: it returns natures of control, nationality, and country of residence; flags overseas corporate PSC entries as a beneficial ownership risk signal; and returns an explanatory note for PLCs with no registrable PSC. This gives an agent useful expectations about non-obvious 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 three concise sentences with no fluff. The first sentence states the core action clearly, and the following sentences list return contents and edge-case behavior. Every sentence adds value, and the structure supports fast agent scanning.

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, read-only tool with a full input schema and an output schema, the description is complete. It explains the primary output, the risk flag, and the no-PSC edge case. Nothing essential is missing for correct selection and 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%, so the schema already documents company_number, including format, length, and that it is returned by company_search. The tool description itself adds no additional parameter-level semantics; the baseline of 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 and resource: 'Fetch Persons with Significant Control (beneficial ownership) for a company.' This precisely names both the action and the entity type, and distinguishes the tool from siblings like company_officers or company_profile by focusing on PSC/beneficial ownership.

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 states the intended context by explaining what kind of data is returned and when a special note is provided for widely-held PLCs. It does not explicitly name alternative tools for comparison, but the PSC/beneficial ownership framing makes the appropriate use case clear enough for an agent to choose this tool over sibling company_* tools.

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?

It adds meaningful behavioral context beyond the read-only annotations: results are sorted by an internal DD severity score, the notice label is a source fact, each result contains a notice_numeric_id, and the Gazette publication is legally effective. This helps the agent interpret results correctly, though rate limits and pagination behavior are not discussed.

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 action, then gives sorting behavior, next-step guidance, and legal context. Every sentence serves a purpose, and the phrasing is compact for a tool with seven parameters and an output schema.

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 has full schema coverage, a rich output schema, and annotations, so the description only needs to supply the interpretative context: sorting semantics, source authority, and the notice:// follow-up. It does adequately, giving the agent enough context to invoke the tool and use its results 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 description coverage is 100%, so the schema already explains every parameter. The description adds modest semantic value by referencing entity-name search and the Gazette notice-code taxonomy, but it does not materially extend what the input 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 clearly names a specific verb ('Search') and resource ('The Gazette's corporate-insolvency notice index'), and adds distinguishing context by stating that results can be followed up via the notice:// resource for full legal wording. This separates it from related tools like gazette_notice and company_search even though those siblings are not explicitly named.

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 context for when this tool is appropriate: searching insolvency notices by entity name, filtering by notice code and date, and then reading full legal text via the notice resource. It does not explicitly list when not to use the tool or name alternative siblings, but the intended usage is strongly implied and supported by the schema.

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 destructive=False, so safety is fully covered. The description adds meaningful behavioral context beyond annotations: it always returns full history, includes dissolved or insolvent companies, and includes historical appointments. This is sufficient, though it stops short of mentioning response shape, which is addressed by the output schema.

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 compact and front-loaded: the main action and result are in the first sentence. Subsequent sentences add workflow, scope, and intent without waste. 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?

Given a simple single-parameter tool with an output schema and complete safety/discovery annotations, the description provides all needed operational context: what the result includes, how to obtain the required identifier, and that there is no approximation. Nothing material is missing for an agent to correctly invoke and interpret this tool.

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 officer_id schema description already explains the type and provenance ('Returned as officer_id on entries from company_officers'). The tool description repeats this workflow context without adding new parameter-level detail, so it stays at the baseline of 3.

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 verb ('Fetch'), resource ('a person's full company appointment history'), and key identifier ('by officer ID'). It also differentiates this tool from the sibling company_officers by explaining that this tool reveals other companies beyond the one used to obtain the officer_id.

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 usage guidance: call company_officers first to get an officer_id, then use this tool to find other appointments. It also states an exclusion condition—there is no current-only filter—so an agent knows when not to expect limited results. This is strong directional guidance relative to sibling tools.

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 rich behavioral detail beyond annotations: matching is deterministic and normalised (case/accent/punctuation insensitive), entity names match reliably but person names with transliteration variants may not, an empty result is not a guarantee of clearance, and false positives are possible. It also explains the meaning of 'lists_screened' and 'as_at' output fields. This substantially exceeds the annotations' readOnly/openWorld/idempotent hints.

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: purpose, use case, matching behavior, caveats, and output fields. Every sentence contributes substantive information; there is no fluff or repetition. The length is justified by the complexity of the tool's behavior.

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 complexity (sanctions screening with nuanced matching and result interpretation) and the presence of an output schema, the description covers all critical aspects: which lists are screened, matching details, interpretation of results, and meaning of key output fields. It is complete and self-contained.

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 adds semantics for the 'name' parameter by explaining how matching behaves (normalised exact/alias match, transliteration caveats), which is not in the schema. It also clarifies that 'entity_type' filters person vs entity, consistent with the schema. This adds value beyond the structured field 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 the tool's function: 'Screen a name against the UK (OFSI), US (OFAC), EU and UN consolidated sanctions lists.' It uses a specific verb ('screen') and specific resource (sanctions lists), and is distinct from sibling tools which focus on company/gazette/land data. The title reinforces the purpose.

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 context: 'Use it to check whether a counterparty — or its officers / persons with significant control — appears on a sanctions list.' It also provides important caveats about what the tool is not for: 'This is a screening aid, not a compliance determination.' While it doesn't name alternative tools (none exist among siblings), the when-to-use and when-not-to-use guidance is 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?

Beyond the annotations (readOnly, idempotent), the description discloses that searches run in parallel and that results are IDs, not full records, requiring a follow-up fetch call. This adds meaningful behavioral expectations.

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 concise, structured in three sentences: what, scope, and how to use results. No redundant words or vague statements.

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 aggregate search tool, the description covers the essential elements: service scope, parallel behavior, and result handling. The output schema and annotations supply additional context, so the description is sufficiently 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?

The input schema already documents the query parameter thoroughly, including its type, length constraints, and semantic meaning. The description does not add additional parameter-level detail beyond what the schema provides, so a baseline score 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 the tool searches all UK due diligence registers simultaneously, naming the specific registers (Companies House, Charity Commission, disqualified directors, Gazette insolvency). This distinguishes it from sibling tools that target individual registers, making 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 specifies this is a cross-register search ('across all UK due diligence registers simultaneously') and that it returns IDs for use with fetch, implying the workflow. It doesn't explicitly state when not to use it or name alternatives, but the sibling tools provide that context.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context: it returns the trading name and address, and notes that this often differs from the Companies House registered address, framing it as a due diligence signal. This goes beyond what annotations alone convey.

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 short paragraphs, each earning its place: core purpose, return-value detail with a practical caveat, and an explicit scope limitation with an alternative. It is front-loaded, efficient, and free of fluff.

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?

This is a simple one-parameter tool with an output schema present. The description covers the return values, the UK-only scope, the external alternative, and a subtle due-diligence nuance. Nothing important is missing for correct selection and 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?

The input schema has 100% description coverage for the single parameter, including accepted formats and normalization behavior. The description itself adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate; the schema already does the heavy lifting.

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 'Validate a UK (GB) VAT number against the HMRC register,' using a specific verb and resource while immediately clarifying the UK-only scope. This clearly distinguishes it from sibling search/profile tools that focus on company or charity data.

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 states 'Non-UK (EU) VAT numbers cannot be validated here — use the EU VIES service for other member states,' providing both an exclusion and a concrete alternative. For UK numbers, the implied use case is clear and unambiguous.

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