registrum-mcp

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

With no annotations, the description carries full behavioral burden and does so thoroughly: partial results are normal, sections may be null for plan or data reasons, compliance requires a Pro plan, financials can be null when no machine-readable accounts exist, verification_status semantics carry over, and only a missing company is an error. This gives a complete null/error handling model.

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 front-loaded with the core purpose, and every subsequent sentence earns its place by addressing an operational concern such as credits, nulls, plan restrictions, and 404s. It is dense with actionable guidance 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?

Despite having no output schema, the description compensates by specifying what each section contains, how nulls should be reported, how plan restrictions affect results, and what constitutes an actual error. An agent has enough context to invoke the tool correctly and interpret responses.

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 both parameters at 100% coverage, including valid include values, omission behavior, and the profile-always-included rule. The description restates this guidance but adds no new parameter-level meaning beyond what the schema provides.

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 ('several views of one UK company in a single request'), and enumerates the five sections. It clearly distinguishes itself from get_company, get_compliance, get_financials, get_psc, and get_directors by framing itself as the batched alternative.

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 to prefer this tool over the five sibling endpoints when multiple views are needed, explaining the benefits: one API call, one credit, one round trip. It also instructs when to pass or omit include, and tells the agent how to distinguish null sections from a genuine 404 missing-company 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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns derived fields like company_age_years and accounts.overdue, which is useful context. However, it does not mention any side effects, data freshness, rate limits, or authentication requirements, and being a read operation, it never explicitly confirms non-mutating 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 two sentences, front-loaded with the main action and resource, then efficiently enumerates the returned fields. Every sentence adds value and there is no redundancy or 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?

For a one-parameter lookup tool with no output schema, the description is quite complete: it lists the main output categories and highlights derived fields that add value. It does not specify the response format or error behaviors, but given the low complexity, this is a minor 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% for the single parameter, with a clear description including format and example. The tool description only repeats 'Companies House number' without adding new meaning beyond the schema, so the parameter semantics are adequately covered by the schema itself.

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 retrieves an enriched profile for a UK company using a Companies House number. This is a specific verb+resource+scope, and the mention of 'enriched profile' distinguishes it from sibling tools like get_directors or get_financials.

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 this is the tool for a comprehensive company profile, but it does not explicitly state when to use it versus sibling tools or mention any exclusions. It notes that derived fields are 'not available from the raw Companies House API', which hints at uniqueness but stops short of naming alternatives or providing when-to-use guidance.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It does this thoroughly: it clarifies that 'pending' is not a failure and must not be reported as one, defines 'overdue,' notes the Pro plan requirement and 24-hour caching, and explains that unverified officers can block filings. This goes well beyond basic safety expectations.

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

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

The description is compact but packs in essential information: purpose, compliance context, exact return fields, and a critical warning about the meaning of 'pending.' The emphasis on 'IMPORTANT' ensures the agent does not misinterpret the status. Every sentence earns its place with no filler.

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

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

Even without an output schema, the description enumerates the exact returned counts (directors_total, directors_verified, directors_pending, directors_overdue, etc.) and the unverified_persons structure. It also covers caching, plan requirements, and the regulatory backdrop, making the tool fully self-explanatory 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 100% for the single parameter company_number, including a pattern, a concrete example, and zero-padding instructions. The description does not repeat or extend the parameter documentation, but given the schema's completeness, a baseline of 3 is appropriate. No additional parameter-level semantic information is needed.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Check a UK company's ECCTA identity-verification status.' It also enumerates what the status includes (verified, pending, overdue) and distinguishes it from sibling tools by focusing on compliance rather than general company data, directors, or PSC information.

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 strong contextual guidance by explaining the ECCTA legal requirement and the enforcement date, which implicitly tells users when they would need this tool. It does not explicitly contrast with alternatives like get_directors or get_psc, but the unique compliance angle and the detail about enforcement make the use case clear. A clear exclusion or explicit alternative would bump this to 5.

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 handles it well: it warns that not every entry is a director, explains the officer_role field and is_board_director boolean, and lists all returned fields. It lacks pagination/auth details, but for a read-only query this is adequate.

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 a single paragraph of moderate length, front-loading the core function then adding the critical caveat and field enumeration. It is informative without being bloated, though it could be broken into shorter sentences for 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?

Without an output schema, the description thoroughly explains all return fields and the officer_role variants, plus the is_board_director boolean and the list of other companies. This gives an agent everything needed to interpret the full response.

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 only parameter company_number is fully documented in the schema with format guidance and an example, so the description adds no extra semantic value. Baseline 3 applies because schema coverage is 100%.

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 retrieves current and past officers for a UK company, and goes further to correct the misleading tool name by explaining the list is the full officer register not just directors. This effectively distinguishes it from siblings like get_psc (ownership) and get_company (basic 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?

It provides clear context on scope (full officer register, corporate history) and says the call gives a full picture in one call, implying it is the comprehensive officer tool. However, it does not explicitly name alternatives or state when not to use it, which would earn a 5.

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 burden and delivers: it explains the data source (iXBRL accounts), details the returned fields including a data_quality block, and discloses a 7-day cache. This provides thorough behavioral context beyond a simple 'get'.

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 with a clear purpose first, then a detailed list of returned data, and finally a behavioral note about caching. Every sentence adds value without redundancy.

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

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

Given the single parameter with full schema coverage and the absence of an output schema, the description thoroughly enumerates all return values, the data source, and caching behavior, making it complete for operational use.

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 description for company_number is 100% covered, including format and example, so the description adds no extra parameter meaning beyond what the schema already states. Baseline of 3 is appropriate.

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

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

The description clearly specifies the verb 'Get' and the resource 'structured financial data for a UK company', and distinguishes it from siblings by focusing on financials parsed from iXBRL accounts. It is unambiguous and directly reflects the tool's function.

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 that this tool is for retrieving financial data from Companies House filings. It implies the appropriate context without naming alternatives or exclusions, which is acceptable given the obvious distinction from sibling tools.

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

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

With no annotations provided, the description carries the burden. It discloses the read-only nature ('Returns all companies...') and details the output fields, which is transparent. It does not warn about potentially large result sets for depth 2 (though the schema does), nor does it explicitly declare itself read-only, so it falls short of fully comprehensive behavioral disclosure.

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 that front-load the core purpose, then describe the return contents and use cases. Every sentence contributes meaning without redundancy.

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

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

Given no output schema and no annotations, the description compensates by specifying return fields and the domain (UK companies, shared directors). It covers the main aspects an agent needs: what it does, what it returns, and when to use it. The only gap is a lack of explicit warnings about result size at larger depths, but the schema addresses that.

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 context linking 'depth' to 'up to the specified depth' and 'shared directors' to 'shared board members', but these are already conveyed in the schema. No additional parameter-level meaning is provided 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 verb 'Map' and the resource 'corporate network connected to a UK company via shared directors', distinguishing it from sibling tools like get_directors or get_company. It also specifies the output contents (company name, number, status, shared directors), making the tool's function unmistakable.

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 explicit use cases ('useful for identifying corporate group structures, related party relationships, and director interlocks') which guides when to apply this tool. However, it does not explicitly name alternative tools for different scenarios or state when not to use it, so it lacks the exclusionary guidance typical of a 5.

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 takes full responsibility and delivers rich behavioral detail: decoded control types, ECCTA verification status semantics, the difference between pending/unknown/overdue, corporate entities lacking verification fields, exemption detection for listed PLCs, and 24-hour caching. This goes well beyond a mere 'returns data' statement.

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 adds operational value: thresholds, decoding, verification semantics, corporate PSC differences, exemptions, and caching. It is front-loaded with the core purpose and then builds logically through data categories and status meanings with no filler.

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

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

Given there is no output schema, the description compensates thoroughly by specifying the types of PSCs, the fields on each, the meaning of verification statuses, and caching behavior. It gives the agent enough information to interpret and use the returned data correctly without over-specifying internal structure.

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 already covers it fully with a pattern, an example, and zero-padding guidance. The description adds context that the company must be UK-based, but most of the parameter documentation already lives in the schema, so the added value is minimal.

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: 'Get the PSC register for a UK company.' It goes on to enumerate exactly what is returned (individuals, corporate entities, legal persons) and the thresholds, making the tool's purpose unambiguous and distinct from sibling tools like get_psc_chain by focusing on the register itself.

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 clearly says the tool is for obtaining a UK company's PSC register, which implies when to use it. However, it does not explicitly state when not to use it or compare it against alternatives such as get_psc_chain, leaving the routing decision partially to the agent.

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 of behavioral disclosure, and it does so thoroughly. It explains recursive traversal, all terminal_reason values, nuances like unverified_registry and unknown_kind, ECCTA identity verification semantics, and which node types carry verification fields. It also proactively warns against misreporting pending or unknown statuses as compliance failures.

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 densely informative, and the length is justified by the tool's complexity and the absence of an output schema or annotations. It is front-loaded with the core purpose, then organizes details into terminal reasons, verification statuses, and metadata. Some phrasing is repetitive, but each part adds useful operational guidance.

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, the lack of annotations, and the absence of an output schema, the description is exceptionally complete. It covers what the returned tree contains, how branches terminate, how verification statuses should be interpreted, and what chain_metadata reports. An agent has enough context to invoke the tool and interpret its results correctly.

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

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

The input schema already covers 100% of the parameters, including max_depth constraints and company_number formatting, so the description does not need to add much. It adds minor context like per-level API cost but does not significantly enrich parameter 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 states a precise verb and resource: "Trace the full ownership chain for a UK company by recursively following corporate entity PSCs." It clearly explains what the tool returns and distinguishes itself from the immediate PSC layer, making it easy to tell apart from sibling 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 explicitly names use cases: KYB checks, AML screening, and any task requiring beneficial ownership beyond the immediate PSC layer. It gives clear context for when to use it versus simpler PSC retrieval, though it does not explicitly enumerate exclusions or alternatives beyond the implied comparison to get_psc.

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 full behavioral burden. It discloses that the tool is a search operation returning a list of matches with specific fields. It doesn't describe rate limits, auth, or pagination, but for a simple read-only search the core behavior is transparent. The description adds scope (UK companies) and return values, which is adequate.

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, front-loaded with the main action and scope, followed by return fields and usage advice. Every 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?

For a simple search tool with two well-documented parameters and no output schema, the description is complete. It states what it searches, what it returns, and when to use it. No output schema exists, but the listed return fields cover the essential information. The description fully suffices for an agent to select and invoke 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 description coverage is 100% for both parameters, so the schema already explains 'query' and 'limit' clearly. The tool description does not add significant semantic detail beyond the schema, staying at the baseline expected when schema carries the load.

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

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

The description clearly states the tool's function: 'Search for UK companies by name.' It specifies the resource (UK companies) and the action (search), and distinguishes it from sibling tools that retrieve specific company details. The return fields are listed, making the purpose unmistakable.

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 explicit usage guidance: 'Use this first when you only have a company name and need its company number.' This tells the agent when to use it, though it doesn't explicitly mention when not to use it or name alternative tools. The phrase 'use this first' implies it's the entry point before using siblings, but exclusions are not stated.

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