registrum-mcp

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, the description carries the full load and does so richly: it discloses the 7-day cache, the available:false failure modes with three distinct reasons (image_pdf, no_ixbrl_filings, dissolved), and explicitly warns that unavailable does not mean no accounts exist. It also flags that abbreviated filings carry no P&L and that accounts_type unknown must not be assumed to be full — behavior an agent would otherwise get wrong.

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

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

Front-loads the purpose and the returned fields before the caveats, and almost every sentence carries unique information. It is dense and long, with the data_quality field breakdown approaching output-schema detail, but with no output schema present that detail is arguably load-bearing.

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

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

There is no output schema, so the description must describe returns, and it enumerates the key figures, the accounts_type/data_quality blocks, the period_end-vs-filed_on distinction, and the unavailable states. An agent has enough to interpret results correctly without further documents.

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 there is a single required parameter, so the schema already documents company_number fully, including the zero-padding rule. The description adds no parameter-level guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Get structured financial data for a UK company') and further scopes it to iXBRL accounts filed at Companies House, which clearly separates it from siblings like get_company or get_compliance.

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

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

Usage is implied by the data source and enumerated fields, but there is no explicit when-to-use vs when-not guidance and no alternative sibling is named (e.g. get_company for profile data). The caveats about abbreviated filings and unavailable:false imply when results will be empty, which is helpful but not framed as routing 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 does so thoroughly: it explains caching (24 hours), that corporate PSCs carry no verification fields, the meaning of verification_status values (pending is not a failure, unknown is absence of data, only overdue is a breach), and the tri-state registry_is_companies_house. These are exactly the behavioral nuances an agent cannot infer from structured fields.

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

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

Front-loaded with purpose before field semantics, and nearly every sentence earns its place by disambiguating a field value. It is a dense unbroken paragraph with no formatting for the many field-by-field rules, and a couple of clauses (e.g. the null-lookup warning) restate the same point, so it is slightly heavier than ideal.

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

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

There is no output schema and no annotations, so the description must supply both the return shape and the behavioral profile; it does, covering PSC types, verification fields, registry fields, kind/kind_raw fallback, exemptions, and cache lifetime. An agent has what it needs to call and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema description coverage is 100%, so the schema already documents company_number, its pattern, and zero-padding. The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

The opening sentence gives a specific verb and resource ('Get the PSC register for a UK company') and the body scopes exactly what is returned (individuals, corporates, legal persons with 25%+ control). It never distinguishes itself from the closely related sibling get_psc_chain, so an agent facing both must guess, which keeps it off a 5.

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

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

Usage is implied by the domain: call it to obtain a company's PSC register. There is no explicit when-to-use, no when-not, and no routing to alternatives such as get_psc_chain or get_directors, which is a real gap given the overlapping sibling. The embedded 'never treat a null as a missing value to look up' is data-interpretation advice rather than tool-selection 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?

With no annotations provided, the description carries the full burden and discharges most of it: it enumerates every terminal_reason, pre-empts two common misreadings (unverified_registry, unknown_kind) as findings rather than errors, explains company_number nullability, and warns against reporting 'pending' verification as a breach. It does not state auth/permission needs or read-only nature, and rate limiting is only hinted at via credit cost.

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

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

The purpose is front-loaded, but the body is a dense wall of text that repeats the same idea ('Both are findings, not errors' / 'which is a finding ... and not an error or an outage'). The terminal_reason semantics earn their space, but the redundancy costs readability.

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

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

There is no output schema, so the description must document the return value, and it does so thoroughly: chain_metadata, terminal_reason values, per-node fields (company_number, registry_number, verification_status group), and which node types lack verification fields. Nothing an agent needs to call or interpret this 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 description coverage is 100%, so both parameters are already documented, including the per-level API cost of max_depth and the zero-padding rule for company_number. The description adds no parameter-level detail beyond what the schema supplies, so the baseline 3 applies.

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

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

States a precise verb and resource ('Trace the full ownership chain... by recursively following corporate entity PSCs') and describes the return shape (a tree terminating in UBOs, foreign entities, or legal persons). It also separates itself from the sibling get_psc by framing the value as 'beneficial ownership beyond the immediate PSC layer'.

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

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

Gives concrete context ('Use this for KYB checks, AML screening, or any task requiring beneficial ownership beyond the immediate PSC layer'), which implicitly routes agents away from get_psc for deep chains. There is no explicit when-not-to-use or cost-based exclusion beyond the chain_metadata cost note.

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.