How do I use companies-house-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@companies-house-mcp search for Apple UK companies" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

companies-house-mcp

by DarkhorseOne

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Companies House MCP Server

A Model Context Protocol (MCP) server that provides AI assistants with access to UK Companies House data. This server enables AI tools to search for companies, retrieve detailed company profiles, officer information, and filing history through the official Companies House API.

Features

Company Search: Search for UK companies by name or keyword
Company Profiles: Get detailed company information including registration details, addresses, and status
Officer Information: Retrieve lists of company officers (directors, secretaries, etc.)
Filing History: Access company filing history and documents
MCP Compatible: Works with any MCP-compatible AI assistant or client

Related MCP server: companieswise

Prerequisites

Node.js 18 or higher
Companies House API key (free registration at Companies House Developer Hub)

Installation

Clone the repository:

git clone <repository-url>
cd companies-house-mcp

Install dependencies:

npm install

Set up environment variables:

cp .env.example .env
# Edit .env and add your Companies House API key

Build the project:

npm run build

Configuration

Create a .env file in the project root:

COMPANIES_HOUSE_API_KEY=your_api_key_here
COMPANIES_HOUSE_BASE_URL=https://api.company-information.service.gov.uk

Getting a Companies House API Key

Visit the Companies House Developer Hub
Create an account or sign in
Register a new application
Copy your API key to the .env file

Usage

Development

Start the development server with hot reload:

npm run dev

Production

Build and start the production server:

npm run build
npm start

Docker

Run using Docker:

docker build -t companies-house-mcp .
docker run -e COMPANIES_HOUSE_API_KEY=your_api_key_here companies-house-mcp

Or use Docker Compose:

docker-compose up

MCP Client Configuration

Local Development (Stdio Transport)

For local development or direct MCP client usage:

{
  "mcpServers": {
    "companies-house": {
      "command": "node",
      "args": ["/absolute/path/to/companies-house-mcp/dist/index.js"],
      "env": {
        "COMPANIES_HOUSE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Cloud Deployment (HTTP Bridge)

For cloud deployment where the HTTP server runs remotely:

Start HTTP server on cloud server:

npm run start:http

Configure client to use HTTP bridge:

{
  "mcpServers": {
    "companies-house-http": {
      "command": "node",
      "args": ["/absolute/path/to/companies-house-mcp/simple-http-bridge.js"],
      "env": {
        "COMPANIES_HOUSE_API_KEY": "your_api_key_here",
        "MCP_HTTP_SERVER_URL": "http://your-server:3000"
      }
    }
  }
}

Note: For cloud deployment, see README-HTTP.md for detailed HTTP bridge configuration.

Available Tools

The server provides the following tools for AI assistants:

1. search_companies

Search for UK companies by name or keyword.

Parameters:

query (string, required): Search query for company name or keyword
items_per_page (number, optional): Number of results to return (default: 20)

Example:

{
  "name": "search_companies",
  "arguments": {
    "query": "Apple",
    "items_per_page": 10
  }
}

2. get_company_profile

Get detailed company profile information.

Parameters:

company_number (string, required): Company number (e.g., "12345678")

Example:

{
  "name": "get_company_profile",
  "arguments": {
    "company_number": "12345678"
  }
}

3. get_company_officers

Get list of company officers (directors, secretaries, etc.).

Parameters:

company_number (string, required): Company number (e.g., "12345678")

Example:

{
  "name": "get_company_officers",
  "arguments": {
    "company_number": "12345678"
  }
}

4. get_company_filings

Get company filing history.

Parameters:

company_number (string, required): Company number (e.g., "12345678")
items_per_page (number, optional): Number of filings to return (default: 25)

Example:

{
  "name": "get_company_filings",
  "arguments": {
    "company_number": "12345678",
    "items_per_page": 50
  }
}

Development

Scripts

Core MCP Server (Stdio):

npm run dev - Start development server with hot reload
npm run build - Compile TypeScript to JavaScript
npm run start - Start production stdio server
npm run type-check - Run TypeScript type checking

HTTP Bridge (Cloud Deployment):

npm run start:http - Start HTTP server for cloud deployment
npm run dev:http - Start HTTP server in development mode
npm run bridge - Start HTTP bridge client

Project Structure

companies-house-mcp/
├── src/
│   ├── index.ts              # Stdio MCP server entry point
│   ├── server.ts             # Core MCP server implementation
│   ├── http-index.ts         # HTTP server entry point
│   ├── http-server.ts        # HTTP server implementation
│   ├── types.ts              # TypeScript type definitions
│   └── services/
│       └── companies-house.ts # Companies House API client
├── simple-http-bridge.js     # HTTP bridge client
├── dist/                     # Compiled JavaScript files
├── .env                      # Environment variables
├── package.json              # Dependencies and scripts
├── tsconfig.json             # TypeScript configuration
├── Dockerfile                # Docker configuration
├── docker-compose.yml        # Docker Compose configuration
├── README.md                 # Main documentation
└── README-HTTP.md            # HTTP bridge documentation

API Rate Limits

The Companies House API has rate limits. Please refer to the official documentation for current limits and best practices.

Error Handling

The server includes comprehensive error handling:

API errors are wrapped in MCP error format
Invalid company numbers return appropriate error messages
Network errors are caught and reported
Missing API keys are detected at startup

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request

License

This project is licensed under the ISC License.

Support

For issues related to:

This MCP server: Open an issue in this repository
Companies House API: Visit the Companies House Developer Hub
Model Context Protocol: Visit the MCP documentation

Disclaimer

This is an unofficial client for the Companies House API. Please ensure you comply with the Companies House API terms of service and data usage policies.

Available Tools

4 tools

get_company_filingsC

Get company filing history

ParametersJSON Schema

Name	Required	Description	Default
`company_number`	Yes	Company number (e.g., 12345678)
`items_per_page`	No	Number of filings to return (default: 25)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral disclosure burden. It only states 'Get company filing history' and omits important traits like pagination (items_per_page param), ordering, date filtering, or return format. No additional context is given.

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 a single concise sentence with no redundant words. It is front-loaded and easy to parse.

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

Completeness2/5

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

Despite having only 2 well-documented parameters and no output schema, the description is too thin. It does not explain what the returned filing history looks like, order, or any limitations. Given the lack of annotations and output schema, more context is needed for complete understanding.

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

Parameters3/5

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

Schema coverage is 100%—both company_number and items_per_page are documented with examples and defaults. The description adds no semantic value beyond the schema, so a baseline score of 3 is appropriate.

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

Purpose4/5

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

Description uses a specific verb ('get') and resource ('company filing history'), clearly distinguishing it from sibling tools like search_companies, get_company_profile, and get_company_officers. While it doesn't explicitly list what filings include, the resource is unmistakable.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusions. The description simply states the operation.

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

get_company_officersA

Get list of company officers (directors, secretaries, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`company_number`	Yes	Company number (e.g., 12345678)

TDQS

A3.5/5.0

Behavior2/5

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 states what it returns (list of officers) but omits any behavior like required authentication, error cases, pagination, or handling of empty results. Minimal disclosure.

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?

Single sentence, front-loaded with the action, and zero wasted words. Concise and easy to scan.

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

Completeness3/5

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

No output schema exists, so the description should clarify return structure. It states 'list of company officers' and type examples, but lacks detail on officer object fields. Adequate for a simple one-param tool, but not complete for programmatic use.

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

Parameters3/5

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

Schema coverage is 100%: the single parameter company_number is fully described with an example. The description adds no extra semantics, but the schema provides sufficient meaning.

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 uses a specific verb+resource: 'Get list of company officers (directors, secretaries, etc.)'. It clearly distinguishes from sibling tools like search_companies (search) and get_company_filings (filings).

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

Usage Guidelines3/5

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

Usage context is implied: use this to retrieve officer details for a given company. No explicit when/when-not guidance or references to alternatives, but the purpose is clear enough for basic selection.

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

get_company_profileC

Get detailed company profile information

ParametersJSON Schema

Name	Required	Description	Default
`company_number`	Yes	Company number (e.g., 12345678)

TDQS

C2.9/5.0

Behavior2/5

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. It only states the action ('Get...information') without indicating whether the operation is read-only, requires authentication, how data is returned, or any side effects. This is insufficient for a tool without structured safety hints.

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 a single, front-loaded sentence with no filler or redundancy. It efficiently conveys the core purpose, making it appropriately concise for a simple getter tool.

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

Completeness2/5

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

The tool has no output schema, so the description should compensate by explaining what 'detailed company profile' includes (e.g., registered address, status, industry codes). The minimal phrasing leaves the agent guessing about the returned data and how it differs from officers or filings, making it incomplete for effective selection and invocation.

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

Parameters3/5

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

The single parameter 'company_number' is fully described in the schema (100% coverage) with an example. The description adds no extra meaning beyond the context of retrieving a profile, which is implicitly clear from the tool name. The baseline of 3 applies because the schema handles parameter documentation.

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

Purpose4/5

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

The description clearly states the tool retrieves 'detailed company profile information', establishing a specific verb and resource. It distinguishes from sibling tools by focusing on profile data rather than search, officers, or filings, though it doesn't enumerate what 'detailed' encompasses.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like search_companies or get_company_officers. The description omits any context about prerequisites, exclusions, or suitability, leaving the agent without decision factors.

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

search_companiesB

Search for UK companies by name or keyword

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query for company name or keyword
`items_per_page`	No	Number of results to return (default: 20)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the search scope and does not mention pagination, result format, rate limits, or read-only nature, leaving significant uncertainty for the agent.

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 a single, front-loaded sentence with no filler. It directly states the core function and is appropriately sized for a simple search tool.

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

Completeness2/5

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

With no output schema and only a minimal description, the agent cannot infer the return structure, pagination behavior, or what fields are included in results. The description fails to provide essential context for a complete understanding of the tool.

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

Parameters3/5

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

The schema fully describes both parameters (query and items_per_page). The description's 'by name or keyword' mirrors the query parameter description, adding no substantial meaning beyond the schema. Baseline 3 is appropriate.

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 specifies the verb 'search', the resource 'UK companies', and the scope 'by name or keyword'. This distinguishes it from sibling tools like get_company_profile, which retrieve specific data for known companies.

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

Usage Guidelines3/5

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

The description implies its use for finding companies by name or keyword, but it does not explicitly state when to prefer this over alternatives (e.g., when the company number is unknown) or provide exclusions. The context is clear but lacks direct guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Aug 2, 2026
- First observedget_company_filings
- First observedget_company_officers
- First observedget_company_profile
- First observedsearch_companies

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-08-02 13:30 across 4 tools

Disambiguation5/5

Each tool targets a distinct aspect of company data: search, profile, officers, and filings. There is no overlap between these operations, and an agent can easily select the correct tool based on the information needed.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: search_ and get_ prefixed to the resource type. This makes the API predictable and easy to navigate.

Tool Count4/5

With only 4 tools, the server is compact but still provides the core look-up operations for a company information API. While not exhaustive, the count is reasonable for a focused, single-domain server.

Completeness4/5

The set covers the primary read-only workflows: finding a company, viewing its details, officers, and filings. Notable omissions like charges or persons of significant control might be expected, but for a basic Companies House integration, the surface is largely complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

UK Companies House Monitor: Filings, Directors & PSC AlertsOAuth
io.github.Nero-Engine
UK company records from Companies House, with alerts on new filings, officer and status changes.
Government Data Open Data
1
CompanyLens AOAuth
io.companylens.mcp
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
Finance Legal & Compliance
172
Companies House A
io.github.pipeworx-io
Companies House MCP — UK statutory company registry (BYO key)
Government Data Open Data
362
api AOAuth
com.datocapital
Official company and director data: search, profiles, filings, and name normalization.
Government Data Open Data
1

Related MCP Servers

Companies House MCP
Government Data Open Data
aicayzer
A
license
Not graded
quality
B
maintenance
Enables looking up UK companies, officers, ownership, filings, and running due diligence checks via the Companies House API, usable from AI tools like Claude or Cursor.
Updated a month ago (2026-08-04 14:46 UTC)
5 npm
13
MIT
companieswiseofficial
Government Data Search Open Data
qinisolabs
A
license
A
quality
D
maintenance
Provides verified UK company lookup and number validation for AI agents using official Companies House data. Enables lookup of registered details by number, validation of company number format, and search by company name.
Updated 3 months ago (2026-06-22 13:14 UTC)
3
27 npm
Apache 2.0
brreg-mcp-server
Government Data Open Data Search
andyarntsen-alt
A
license
A
quality
D
maintenance
Enables AI agents to search and retrieve Norwegian company data from the Brønnøysund Register Centre's open API, including company details, roles, and subunits.
Updated 7 months ago (2026-02-17 18:24 UTC)
5
5 npm
MIT
companies-house-mcp
Government Data Search
mikeyhu
F
license
B
quality
C
maintenance
Provides access to UK Companies House public data, enabling search and retrieval of company profiles, officers, filing history, and more through natural language queries.
Updated 2 months ago (2026-07-15 08:03 UTC)
12
-

Companies House MCP Server

Features

Prerequisites

Installation

Configuration

Getting a Companies House API Key

Usage

Development

Production

Docker

MCP Client Configuration

Local Development (Stdio Transport)

Cloud Deployment (HTTP Bridge)

Available Tools

1. search_companies

2. get_company_profile

3. get_company_officers

4. get_company_filings

Development

Scripts

Project Structure

API Rate Limits

Error Handling

Contributing

License

Support

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

companieswiseofficial