UK Business Tools - Ledgerhall

Overview Schema Source Related Servers Discussions Admin

Get Officer Appointment History

dd_officer_appointments

Read-onlyIdempotent

Uncover a person's full UK company appointment history by officer ID, including current and past roles at dissolved or insolvent companies not found elsewhere.

Instructions

Fetch a person's full company appointment history by officer ID.

Returns every appointment — current and historic — with each company's number, name, status, role, and appointment/resignation dates. Use company_officers first to find an officer_id, then this tool to discover other companies that person has been a director or secretary of, including dissolved or insolvent ones not mentioned anywhere else. Always returns full history; there is no current-only filter, since historical discovery is the point.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`officer_id`	Yes	Companies House officer ID. Returned as officer_id on entries from company_officers.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	No	Officer name as recorded at CH.
`total`	Yes	Total appointments returned.
`officer_id`	Yes	Companies House officer ID.
`active_count`	No	Upstream count of appointments Companies House categorizes as 'active' — this reflects the officer's own appointment/resignation state at that company, NOT whether the company itself is currently trading. An appointment at a company in liquidation or administration still counts as active here if the officer was never formally resigned. Check each appointment's own company_status field for the company's actual status. Null if not provided upstream.
`appointments`	No	Every appointment, current and historic.
`date_of_birth`	No	Partial date of birth (month/year), or empty if not disclosed upstream.
`inactive_count`	No	Upstream count of appointments Companies House categorizes as 'inactive', passed through as-is. Exact categorization semantics have not been independently verified against per-appointment data — treat as an unverified upstream fact, not a derived signal, or null if not provided.
`resigned_count`	No	Upstream count of resigned appointments, or null if not provided.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Sep 21, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already carry safety profile, and description adds behavioral detail: it returns both current and historical appointments, includes entries for dissolved or insolvent companies not found elsewhere, and always returns full history. It does not add rate-limit or auth context, but description goes beyond the annotations.

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

Conciseness4/5

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

The description is front-loaded with the core purpose, and all information is directly relevant. The second sentence is somewhat long, but its chain details are essential for correct historical discovery; the final version re-emphasizes the full-history behavior.

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

Completeness5/5

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

With a single required parameter, an output schema, and strong annotations, the description is fully sufficient. It includes the preceding workflow step, what the tool returns, its unique historical value, and a flag behavioral constraint about no current-only filter.

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

Parameters4/5

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

There is only one parameter and the schema coverage is 100%, so the schema already documents officer_id thoroughly. The description adds workflow context by saying the ID comes from company_officers, which helps an agent know how to find and supply it correctly.

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

Purpose5/5

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 a person's full company appointment history by officer ID." It clearly differentiates this tool from siblings by emphasizing historic and dissolved/insolvent appointments, setting it apart from current-officer and profile tools.

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

Usage Guidelines5/5

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

The description explicitly instructs the agent to use company_officers first to obtain an officer_id, then use this tool for historical discovery. It also states the limitation clearly: "Always returns full history; there is no current-only filter, since historical discovery is the point."

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

Deploy Server