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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that partial results are normal, null sections mean 'not available' rather than failure, only a missing company is an error and produces a 404, compliance requires a Pro plan, and ECCTA verification_status rules apply to individuals.

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 dense but every sentence earns its place: the core purpose is front-loaded, followed by usage preference, parameter guidance, null semantics, and error behavior. There is no filler or repetition of schema details.

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 tool with no output schema and no annotations, this description is remarkably complete. It explains what the response contains, how to interpret missing sections, when to use alternatives, and what constitutes an actual error, leaving no critical ambiguity 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?

Schema coverage is already 100%, but the description adds meaning beyond the schema: omitting include fetches all five sections, the profile is always returned, and each section matches what its standalone endpoint returns. This gives the agent the behavioral context needed to choose the right parameter combination.

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 and resource: getting several views of one UK company in a single request, explicitly listing profile, compliance, financials, PSCs, and directors. It clearly differentiates itself from the individual sibling tools by positioning itself as the aggregate request.

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 to prefer this over calling get_company, get_compliance, get_financials, get_psc, and get_directors separately, and explains the benefit: one API call, one credit, one round trip. It also instructs when to use the include parameter versus omitting 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states that the tool returns an enriched profile and lists returned fields, including derived fields like company_age_years and accounts.overdue that are not available from the raw Companies House API. The read-only nature is clear from 'Get', and no contradictory side effects are implied.

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 with no filler. The purpose is front-loaded, and the detailed field list in the second sentence earns its place because it tells the agent exactly what data will be returned and highlights the unique derived fields.

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 single-parameter get tool with no output schema, the description is largely complete: it identifies the required input, the company jurisdiction, and the returned profile contents. It does not cover error or not-found behavior, but that is a minor gap for a low-complexity lookup 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 schema already documents the parameter thoroughly with pattern, example, and zero-padding instruction. The description only says 'by its Companies House number', adding little beyond the schema, 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 ('Get') and resource ('enriched profile for a UK company by its Companies House number'), and enumerates the exact fields returned. This clearly distinguishes it from siblings like get_financials, get_directors, and get_compliance, which target narrower aspects of a company.

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 clear that the tool is for retrieving a company profile when the Companies House number is known, and the field list implies when it is useful. However, it does not name any alternatives or exclusions, such as using search_company when the number is unknown, so usage guidance remains implicit rather than explicit.

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?

No annotations are provided, so the description carries the full burden. It explicitly discloses that the tool returns counts and unverified_persons details, clarifies the critical distinction between 'pending' and 'overdue', and mentions the 24-hour caching and Pro plan requirement. This is thorough behavioral disclosure beyond just naming the operation.

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 necessary context, return shape, important caveats, and operational details. Each sentence earns its place; the legal context is not filler because it explains the relevance of 'overdue' and enforcement. Despite length, it remains focused and 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?

Given there is no output schema, the description thoughtfully explains exactly what will be returned and how to interpret ambiguous terminology. It covers plan requirements, caching, and deadline implications. The single-parameter tool is simple, and the description leaves little an agent needs to infer.

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 provides 100% coverage of the single parameter, including format, example, and zero-padding guidance. The description adds nothing new about company_number beyond implying it identifies the company. Baseline 3 is appropriate because structured schema already documents the parameter well.

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 clearly identifies the resource (a UK company's ECCTA identity-verification status) and the specific action (check). It distinguishes itself from siblings by focusing on compliance/verification state rather than raw company or officer data. The return fields are named, leaving 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?

The description gives clear context for when this tool is appropriate: whenever a director or PSC's ECCTA identity-verification status is needed. It does not explicitly name alternatives or exclusion conditions, but the compliance-specific language makes the intended use obvious. The Pro plan requirement is also stated.

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

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

With no annotations, the description carries full disclosure burden and does so exceptionally well. It reveals the critical behavior that not every entry is a director, lists example officer_role values, explains the is_board_director flag, and instructs the agent to report each person by their actual role. It also discloses the nested list of other companies, making response behavior predictable.

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 action, followed by necessary clarifications and field enumeration. It is longer than minimal, but each sentence adds value, especially the role-reporting instruction that prevents a common misuse.

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?

Since there is no output schema, the description compensates by listing each officer's fields, roles, and the nested other-company appointments, while also warning about the director misnomer. Minor gaps remain, such as pagination and error behavior, but they are not critical for a single-parameter read 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?

The input schema already has 100% coverage, including a description, pattern, and an example for company_number. The tool description adds no additional parameter semantics, 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?

States a specific verb ('Get') and resource ('current and past officers for a UK company'), and explicitly distinguishes the tool from its misleading name by clarifying it returns the full officer register, not just directors. This clearly separates it from related sibling tools like get_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?

Provides clear context about scope: current and past officers, full register, and corporate history, so an agent can infer when to use it for officer-related queries. It does not explicitly exclude alternatives such as get_psc or get_network, but the described data makes the use case evident.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does well: it reveals the iXBRL source, the 7-day cache, the accounts-type classification, and the data_quality block that indicates missing fields. It does not cover failure modes such as missing filings, but the data_quality block partially addresses that concern.

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 layers specific return fields, metadata, and cache behavior. Every sentence adds distinct value and the length is appropriate given there is no output schema to document the return shape.

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 only one parameter, no output schema, and no annotations, the description is largely complete for invocation: it specifies input, return contents, data_quality reporting, and caching. It could be more explicit about currency/units and the exact nested shape of data_quality, but those are secondary to 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 schema already provides 100% coverage for the single parameter, company_number, including pattern, example, and zero-padding guidance. The description adds little beyond confirming the tool applies to UK companies, 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 names a specific verb and resource ('Get structured financial data for a UK company') and then enumerates the exact fields returned, the source filing type, and the extra metadata blocks. This clearly distinguishes it from the sibling tools like get_company, get_directors, or get_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 makes it clear what data the tool returns, so an agent needing financial statements can infer it is the right choice. However, it never contrasts this tool with its siblings or states when not to use it, leaving the alternative selection to inference rather than explicit 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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only behavior ('Map... Returns'), explains traversal semantics ('all companies connected through shared board members, up to the specified depth'), and describes the output fields. It does not mention pagination or de-duplication, but the schema's depth warning helps cover volume concerns.

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: one sentence for purpose, one for output and traversal, and one for use cases. Each sentence earns its place with 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?

Given there is no output schema, the description compensates by enumerating returned fields (name, number, status, shared directors) and explaining the depth parameter's effect. It lacks explicit error or pagination behavior, but for a simple two-parameter read tool, the description plus schema provide sufficient context.

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%, with both parameters already having detailed descriptions. The tool description adds only generic references like 'focal company' and 'specified depth,' which do not meaningfully extend the schema's parameter documentation. 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 clearly states the action ('Map the corporate network') and the resource ('connected to a UK company via shared directors'). It distinguishes itself from siblings like get_directors by focusing on the interconnected network of companies rather than a single company's director list. The scope and output are explicitly described.

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 use cases: 'identifying corporate group structures, related party relationships, and director interlocks.' It does not explicitly name alternative tools or state when not to use it, but the network-specific framing makes its applicability clear relative to single-entity siblings.

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

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

With no annotations, the description carries the full burden, and it delivers. It discloses decoded control types, ECCTA verification fields, the precise meaning of pending vs unknown vs overdue, that corporate entities carry a company number and no verification fields, detection of PSC exemptions, and a 24-hour cache. This goes far beyond a simple 'returns PSC data' and gives the agent a clear model of tool 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?

Although the description is lengthy, every sentence serves a purpose: core function, return types, control-type decoding, verification status semantics, corporate vs individual differences, exemptions, and caching. It is front-loaded with the primary purpose and then layers detail in a logical order. No filler or 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?

Without an output schema, the description must explain return values, and it does so thoroughly. It covers PSC categories, control types, verification status fields and their interpretations, corporate entity specifics, exemptions, and caching. For a complex tool returning varied entity types, this is sufficient for an agent to cal it correctly and interpret the 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?

The input schema already documents company_number with an example and zero-padding guidance, and schema description coverage is 100%. The description does not add any additional parameter-level meaning or nuance, so it stays at the baseline 3. It correctly focuses on output behavior rather than re-explaining the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Get the PSC (Persons with Significant Control) register for a UK company.' It then enumerates exactly what is returned (individuals, corporate entities, legal persons) with ownership thresholds, which clearly distinguishes it from sibling tools like get_directors or get_company. The content is unambiguous and informative.

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 provides clear context on what the tool returns, but it never explicitly states when to use this tool vs alternatives such as get_psc_chain or get_company. No exclusion criteria or alternative routing is given. The usage scenario is implied by the specialization to PSC registers, but the agent is left to infer when this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden. It discloses recursive traversal behavior, the full set of terminal_reason values, including nuanced meanings for unverified_registry and unknown_kind, and details ECCTA identity verification fields with explicit warnings about pending not being a failure and never describing companies as having unverified identity. This goes far beyond a simple description, covering output structure and edge-case semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place: it starts with core purpose, enumerates terminal reasons, flags misinterpretations, details ECCTA fields, and closes with use cases. The structure is logical—purpose, behavior, caveats, use—without redundancy. It is dense with information and properly 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 the tool's complexity (recursion, multiple termination reasons, ECCTA status handling) and the absence of an output schema, the description covers all essential information: the tree structure, node fields, terminal_reason semantics, verification status meaning, and chain_metadata. It even pre-empts likely agent missteps. Nothing an agent needs to call or interpret the tool 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% for both parameters; the schema already documents max_depth's range and per-company cost, and company_number's pattern and padding rule. The description adds no additional parameter detail beyond what the schema provides. The baseline of 3 is appropriate since the schema 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 a specific verb-resource pair ('Trace the full ownership chain') and immediately distinguishes itself from the immediate-PSC sibling by stating it returns a tree of ultimate beneficial owners. It explicitly contrasts with 'beyond the immediate PSC layer,' so an agent can tell it apart from get_psc without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final sentence states explicit use cases ('KYB checks, AML screening, or any task requiring beneficial ownership beyond the immediate PSC layer'), which both says when to use it and implicitly when not to (for immediate PSC layer). It also lists the terminal_reason values and clarifies their interpretation, so an agent knows when the tool is appropriate.

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?

No annotations are present, so the description carries the full burden. It does disclose the return shape: a list of matching companies with company number, status, type, and registered address. However, it does not describe edge-case behavior such as partial matching, empty results, ordering, or pagination, which limits transparency for such a sparse tool.

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, front-loads the core action and result, and adds a clear usage note in only two sentences. Every sentence contributes useful information with no 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?

For a simple list-search tool with two well-documented parameters, the description is mostly complete: it states the target population, the result fields, and the primary use case. Since there is no output schema, the described return fields are helpful. It could be slightly stronger by noting behavior when multiple companies share similar names, but that is not a major gap.

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 both parameters. The description adds little beyond reinforcing that the search is by company name and that the company number is a key output. It does not introduce new parameter-level meaning.

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 a specific verb ('Search'), a specific resource ('UK companies'), and the key output (company number, status, type, registered address). The phrase 'Use this first when you only have a company name and need its company number' distinguishes it from the get_* sibling tools that expect a company identifier.

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 tells the agent when to use the tool: when only a company name is available and a company number is needed. It does not list explicit exclusions or compare with alternatives, but the usage context is clear enough to route decisions correctly.

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