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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds behavioral context by listing specific returned data (trustees, income, insolvency flags, etc.), which is beyond 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?

Two concise sentences: first states purpose, second lists key returned data and usage hint. No extraneous words.

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 an output schema present and a single required parameter, the description sufficiently covers usage and key data. No gaps given the tool's simplicity.

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 'charity_number' is well-described in the schema. The description mentions 'charity number' but adds no new semantics 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 clearly states 'Fetch the full Charity Commission profile' and specifies the input as 'charity number'. It lists returned data (trustees, income, etc.) and distinguishes from the sibling 'charity_search' which finds the number.

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 advises 'Use charity_search first to find the charity number.' This provides clear when-to-use guidance and differentiates from the 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, 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, destructiveHint, idempotentHint, openWorldHint, so safety is clear. Description adds pagination behavior and output fields, complementing annotations well.

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 adding value: main action, output details, sibling reference, pagination advice. No redundant phrases, well 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?

Presence of output schema reduces need to describe return values. Description covers essential fields, pagination, and links to company_profile, making it complete enough for a search 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 has 100% description coverage with all parameters documented. Description adds minimal extra meaning beyond the schema, such as calling query a keyword search. 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?

Description explicitly states searching the register by company name/keyword and lists returned fields. It distinguishes from sibling company_profile by directing users to it for full records.

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 clear pagination instructions and directs to company_profile for detailed records, but does not mention when to avoid the tool or compare with other siblings like charity_search.

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 provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds specific return fields (reason, Act/section, period, company names), which is useful beyond 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?

Two sentences, no filler. Efficiently conveys purpose, prerequisite, and return content.

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 an output schema present, the description covers the essential prerequisite and return structure. Fully adequate for a simple fetch 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% with description for officer_id. Description restates the origin of the officer ID but does not add new parameter semantics beyond the schema. 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?

Clearly states verb 'Fetch' and resource 'full disqualification record for a director'. Distinguishes from sibling disqualified_search by specifying the prerequisite to first search for 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?

Explicitly instructs to use disqualified_search first to obtain the officer ID, and states what the tool returns. Provides clear context for when and how to use the 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?

Annotations already provide readOnlyHint, idempotentHint, destructiveHint=false. The description adds important context: query must be an individual's name, not a company, and lists return fields. This goes beyond 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?

Five concise sentences, front-loaded with purpose, no fluff. Every sentence adds essential information.

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 4 optional parameters and an output schema, the description covers the tool's scope, usage, constraints, and return fields. It also links to the sibling for further detail, so it is fully sufficient.

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 clarifies that 'name' is an alias for 'query' and reiterates that company names yield zero results, adding modest extra value.

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 checks if a named individual is banned as a UK director, distinguishing it from sibling tools like company_search (companies) and disqualified_profile (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?

Explicitly says when to use ('check disqualified, banned, or barred directors'), what not to query (company names), and mentions the sibling disqualified_profile for full details.

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 annotations (readOnly, etc.), the description adds valuable context: routing behavior by prefix and what each route returns (full profile, record, legal text). This enhances understanding of the tool's behavior.

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: a single header sentence followed by a clear bullet list. No redundant information, effectively front-loading the key action.

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, output schema, and annotations, the description thoroughly covers the tool's purpose and routing. It could optionally clarify differences from specific profile siblings, but overall it's 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 schema already documents the parameter format. The description adds the routing mapping from prefix to register, which is not in the schema, providing additional semantic value beyond the 100% 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 clearly states it fetches full records for IDs from search and details routing by prefix. It distinguishes from siblings by being a generic fetch tool, though it does not explicitly differentiate from specific profile tools like 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 implies use after search to get full records, but does not explicitly state when not to use this tool or provide alternatives. No exclusion or comparison with sibling tools is given.

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?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by specifying the output structure: 'complete JSON-LD linked-data record for the notice: parties, legal basis, court, and full text.' This provides context beyond 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 concise sentences: first states purpose, second describes return content, third provides usage guidance. Every sentence is essential and front-loaded. No redundancy 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?

The tool has an output schema (true) and annotations covering safety. The description lists key return fields and references pipelining with a sibling tool. This is fully adequate for an agent to understand when and how to use the 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%. The input schema already describes 'Numeric Gazette notice ID. Returned as notice_numeric_id by gazette_insolvency.' The description does not add additional parameter semantics, so 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 clearly states 'Fetch the full legal wording of a Gazette notice by numeric notice ID.' It specifies the verb (fetch), the resource (Gazette notice full text), and the method (by numeric notice ID). This clearly distinguishes from sibling tool gazette_insolvency.

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 instructs 'Use gazette_insolvency first to find notice_numeric_id values.' This provides clear when-to-use guidance and directs the agent to a prerequisite tool, effectively preventing misuse.

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 false. The description adds that the tool returns up to 10 recent transactions and covers only England and Wales, which is beyond what annotations provide. 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 four sentences, all front-loaded with essential information. Every sentence adds value: purpose, output scope, geographic coverage, and input advice. No wasted words.

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 simplicity (one parameter, output schema exists), the description covers purpose, input requirements, output summary, and limitations (10 results, England and Wales). Annotations provide safety and idempotency info, making this complete for typical usage.

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. The tool description reinforces that postcode is most reliable and that a full address works, adding practical guidance beyond the schema's type and length constraints.

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 HM Land Registry Price Paid Index by postcode or address, and specifies the output fields (price, date, address, property type, tenure) and geographic scope (England and Wales). This distinguishes it from sibling tools that deal with charities, companies, or other 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 advises using a postcode for most reliable results and notes that a full address is accepted with automatic extraction. While it doesn't explicitly list when-not-to-use or alternatives, the context of sibling tools makes the usage domain clear. A slight gap is the lack of mention of result limits or data freshness.

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?

Annotations (readOnlyHint, openWorldHint, idempotentHint) are fully supported by the description, which adds details on matching algorithm (case-/accent-/punctuation-insensitive), deterministic nature, and partial result conditions. 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 concise and well-structured, with a clear first sentence stating purpose, followed by output explanation, usage guidance, and matching details. Every sentence adds value with no 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?

Given the complexity of sanctions screening, the description is highly complete: it covers matching algorithm, limitations, output fields, and caveats about empty results and false positives. An output schema exists but the description already explains return values sufficiently.

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 description adds significant value beyond the schema: it explains the matching behavior, transliteration uncertainties, and the meaning of output fields, which aids correct interpretation.

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 title and description clearly state that the tool screens a name against multiple sanctions lists (UK, US, EU, UN). The verb 'screen' and resource 'sanctions lists' are specific, and there is no sibling tool with similar 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 explicitly states when to use it (check counterparty against sanctions lists) and provides important caveats: empty result is not clearance, deterministic matching limitations, and screening aid only. It also explains output fields like lists_screened and as_at.

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, destructiveHint, idempotentHint. The description adds behavioral details: parallel search across registers and the ID-based retrieval pattern, without contradicting 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 concise sentences: purpose, details, result workflow. Front-loaded and no extraneous information.

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 schema, existence of output schema, and annotations, the description covers all essential aspects: what it searches, how it returns results, and the follow-up action (fetch).

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 'query' has a detailed schema description (100% coverage). The tool description reiterates types of queries but does not add new semantic information 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 clearly states the tool searches across all UK due diligence registers simultaneously, listing specific registers (Companies House, Charity Commission, etc.). This distinguishes it from individual register search siblings like company_search and charity_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?

The description implies when to use (broad cross-register search) and the workflow (returns IDs to fetch later). It does not explicitly state alternatives or when not to use, but the context of sibling tools makes it 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, etc. The description adds useful behavioral context: returns trading name and address, and notes that the VAT address often differs from Companies House address as a due diligence signal. This goes beyond what annotations provide.

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?

Concise, well-structured, with no unnecessary words. Three short paragraphs: purpose, output, and scope limitation. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with high schema coverage and an output schema (not shown but present), the description fully explains the tool's purpose, output, and limitations. No 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 schema description already explains format and normalization. The description adds context about what the parameter is used for and what the tool returns, but does not add strictly new parameter semantics. A 4 is appropriate for the added contextual value.

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?

Describes exactly what the tool does: validate a UK VAT number against the HMRC register. The verb 'validate' and resource 'UK VAT number (HMRC)' are specific. It is clearly distinct from sibling tools like company_search or sanctions_screen.

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 states UK numbers only and directs users to the EU VIES service for non-UK numbers. Provides clear when-to-use and 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.