UK Business Tools - Ledgerhall

Get Company Filing History

dd_company_filing_history

Read-onlyIdempotent

Fetch one page of a company's Companies House filing chronology.

Returns the raw source facts for each filing — transaction ID, form type/category, dates, and the description_values CH uses to render its own text — as delivered upstream, not interpreted into DD conclusions. links.document_metadata on each filing is the identifier a future document-retrieval tool would need; no document content is fetched here.

Unlike company_officers/company_psc/company_charges, this does NOT auto-fetch every page — a long-lived company's filing history is unbounded in practice (a decades-old PLC can carry thousands of filings). total_count/returned/has_more are always reported truthfully for whatever page and category filter was requested; nothing is silently truncated. Narrow with category= for a specific slice (e.g. category='mortgage' for charge-related filings, category='insolvency' for administration/liquidation filings) — a note is included when an unfiltered history is large.

A company_number that doesn't resolve to any company returns a structured not_found error, distinct from a genuine zero-filing result — Companies House's filing-history endpoint alone cannot tell these apart, so existence is confirmed separately when the result would otherwise be empty.

Input Schema

TableJSON Schema

Name	Required	Description
`category`	No	Filter by CH filing category — comma-separated for multiple, e.g. 'mortgage' or 'mortgage,officers'. Omit for all categories. Common values: accounts, confirmation-statement, officers, address, capital, mortgage, persons-with-significant-control, incorporation, insolvency, resolution, annual-return, change-of-name, change-of-constitution, gazette, miscellaneous.
`start_index`	No	Pagination offset. Default 0. Re-call with start_index=start_index+returned while has_more is true.
`company_number`	Yes	Companies House company number (8 digits, e.g. '03782379'). Returned by company_search.
`items_per_page`	No	Results per page (Companies House caps at 100 regardless of a higher value). Default 100.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Advisory note, e.g. suggesting a category filter when total_count is large and no category was applied. Informational only — never a truncation.
`filings`	No	Filings on this page.
`category`	No	The category filter applied to this query, or null if unfiltered.
`has_more`	Yes	True if start_index + returned < total_count.
`returned`	Yes	Filings returned on this page.
`start_index`	Yes	Pagination offset used for this page.
`total_count`	Yes	Total filings matching this query (across all pages).
`company_number`	Yes	Companies House company number.
`items_per_page`	Yes	Page size actually used (CH caps at 100 regardless of a higher request).
`filing_history_status`	No	Upstream filing-history status (e.g. 'filing-history-available').

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses key behaviors: it returns raw upstream facts not interpreted DD conclusions, does not fetch document content, reports total_count/returned/has_more truthfully, and never silently truncates. It also explains the not_found error distinct from an empty result.

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

Conciseness5/5

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

The description is well-structured into a first-sentence summary, a core behavior paragraph, and a pagination/filtering/error paragraph. Every sentence provides necessary context, and the most critical information is front-loaded.

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?

The tool is a one-page API read with 4 parameters and an output schema. The description adequately covers what is returned, how pagination works, making important distinctions from sibling tools, and how to handle errors, making it comprehensive for an agent to call correctly.

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?

Schema coverage is 100%, so the description doesn't need to restate parameter details. However, it adds value by giving category filter usage examples (category='mortgage', 'insolvency') and clarifying the pagination re-call pattern with start_index=start_index+returned. This complements the schema's already detailed descriptions.

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 clearly states the tool fetches one page of a company's Companies House filing chronology, with a specific verb ('fetch') and resource. It distinguishes itself from sibling tools (company_officers/psc/charges) by emphasizing it does not auto-fetch every page and does not fetch document content.

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?

Explicitly guides when to use this tool versus alternatives: it does NOT auto-fetch every page unlike related tools, advises narrowing with category= for specific slices, and notes document retrieval is not performed here. The description also explains how to handle not_found versus zero-filing results.

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

All UK Business Tools - Ledgerhall tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Tools are well-grouped by domain prefixes (dd_, gov_, law_, prop_) with clear descriptions that differentiate them. However, there is minor overlap, e.g., dd_search could be used instead of individual searches, and dd_fetch versus dedicated profile tools might cause confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with domain-specific prefixes (dd_, gov_, law_, prop_). Names are descriptive and predictable, e.g., dd_charity_search, gov_govuk_search, law_bills_search_bills.

Tool Count4/5

70 tools is high but justified by the broad scope covering due diligence, government, legal, and property domains. Each domain has a reasonable number of tools (about 15-20 each). The count is on the upper end but still manageable.

Completeness5/5

The tool set is comprehensive across all domains: full CRUD for companies and charities, detailed legal research (cases, legislation, parliament, citations), property data (EPC, planning, price paid, rentals), and government information. No obvious gaps for the intended use cases.

Resources

Need Help?