The companieswise server provides tools for looking up, validating, and searching UK company information from an official Companies House data snapshot.
lookup_company: Retrieve a UK company's official registered details (name, status, type, incorporation date, registered-office postcode, and primary SIC code) by its Companies House number. Returns "not found" if the company isn't in the snapshot.
validate_company_number: Check whether a UK company number is well-formed (8 digits, or a 2-letter prefix + 6 digits) and identify what its prefix means (e.g. SC = Scotland, NI = Northern Ireland, OC = LLP). Format-only — does not confirm the company exists.
search_company: Find a company's number by searching its registered name with keywords. Returns companies whose name contains all searched words, with a configurable result limit (default 20).
Key caveats:
Data is a monthly snapshot — not real-time.
Dissolved companies are generally absent from the dataset.
Not legal, financial, or KYC/AML advice.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@companieswise look up company 00445790"
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.
Verified UK company lookup & number validation for AI agents — official Companies House data, not guesses.
Verified, trustworthy data tools for AI agents. "Qiniso" means "truth" in Zulu.
Website · npm · MCP Registry
Ask an LLM "what's the registered name and status of company 00445790?" and it will answer confidently — and usually wrongly: invented names, the wrong status, a fabricated incorporation date. Company records live in the Companies House register, not a model's weights. companieswise looks the number up in the official Companies House snapshot and returns the real registered details — or an honest "not found" instead of a guess.
UK-wide (England & Wales, Scotland, Northern Ireland).
A monthly snapshot of the live register. Company status is as of the dataset date, not real-time — a company dissolved last week may still read "Active" until the next snapshot, and dissolved companies are generally absent. For current status, check the live register.
Not advice. Not legal, financial, credit, or KYC/AML advice, and not a substitute for statutory due diligence.
Related MCP server: Companies House MCP
{ "mcpServers": { "companieswise": { "command": "npx", "args": ["-y", "companieswise"] } } }Then load the real data once (the package ships with only a small sample):
npx -p companieswise companieswise-updateThis downloads the latest monthly Companies House snapshot (~tens of MB) to a local cache. Re-run it whenever you want to refresh; a GitHub Action rebuilds the snapshot monthly, so companieswise-update always fetches the current month. Until you run it, validate_company_number works fully and lookup_company/search_company clearly say they're on the sample.
By default companieswise serves the monthly snapshot (offline, no key). If you set a free Companies House API key, it switches to live queries against the official Companies House API instead — real-time register status, including dissolved companies, on your own key (no shared rate limit):
{
"mcpServers": {
"companieswise": {
"command": "npx",
"args": ["-y", "companieswise"],
"env": { "COMPANIESWISE_CH_API_KEY": "your-companies-house-api-key" }
}
}
}lookup_company and search_company use the live API when the key is set (results tagged "dataset": "live") and fall back to the snapshot when it isn't ("dataset": "snapshot"), so it's always clear which you're getting. validate_company_number is offline either way. The key is sent only to the official Companies House API. CH_API_KEY is accepted as an alias.
npm i companieswiseimport { lookupCompany, validateCompanyNumber, searchCompany } from "companieswise";
validateCompanyNumber("SC123456"); // { valid: true, prefix: "SC", meaning: "Company registered in Scotland" }
validateCompanyNumber("6").number; // "00000006" — normalises/zero-pads
lookupCompany("00000006"); // official name, status, type, incorporation date, postcode, SIC — or found:false
searchCompany("greggs"); // companies whose registered name contains your wordsA well-formed number that isn't in the snapshot returns found: false with a clear note — it never invents a company.
Tool | What it answers |
lookup_company | A company's official registered details by number (name, status, type, incorporation date, registered postcode, primary SIC) |
validate_company_number | Is this a well-formed UK company number, and what does its prefix denote? (format only — there is no check digit) |
search_company | Reverse lookup — find a company's number from its name |
The data is the Companies House Free Company Data Product (UK-wide, live register), published under the Open Government Licence v3.0. Because the real dataset is ~5.6M companies — far too large to bundle into an npm package — the design splits code from data:
Code ships on npm (tiny).
Data is built monthly by a GitHub Action (.github/workflows/refresh-data.yml) that downloads the official snapshot, compiles a compact artifact, and publishes it as a GitHub Release asset.
companieswise-update downloads that artifact into a local cache; every response reports its datasetVersion (the snapshot date).
No API key, no rate limit, no per-request cost — lookups run locally against the cached snapshot. See ARCHITECTURE.md for why, and the hosted/real-time path.
Not real-time. Monthly snapshot of the live register; status is as of the dataset date. For live status use the Companies House API/website.
Not the full register. The free snapshot is live companies; dissolved companies are generally absent (absent ≠ "never existed").
Not advice, and not a statutory KYC/AML check.
Not a guesser — unknown numbers return an honest "not found".
This tool runs locally on your machine and is built not to collect, store, or transmit your data — no analytics, no telemetry, no account. By default it uses bundled/cached data offline; only if you set a Companies House API key does it send your lookup and key directly to the official Companies House API (never to Qiniso). Full policy: https://qinisolabs.github.io/privacy.html.
Apache-2.0. Company data © Crown copyright, Companies House, Open Government Licence v3.0; see NOTICE.
USE THIS to get a UK company's official registered details by its Companies House number — instead of recalling them, which models get wrong (invented names, wrong status). Returns the registered name, status, company type, incorporation date, registered-office postcode and SIC code from official Companies House data, or an honest 'not found'. By default a MONTHLY snapshot (status as of the dataset date; dissolved companies generally absent). Set a free Companies House API key (env COMPANIESWISE_CH_API_KEY) for real-time data incl. dissolved companies. UK-wide (England & Wales, Scotland, NI).
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The UK company number, e.g. '00000006' or 'SC123456' (spaces/case ignored). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: default monthly snapshot, absence of dissolved companies, real-time option with API key, and honest 'not found' return. Clearly communicates data freshness and scope.
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?
Description is informative and flows logically: use case, return fields, data source limitations, optional enhancement. Each sentence adds value, though slightly verbose; could be more concise without losing meaning.
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 single-parameter lookup tool, description is remarkably complete: explains return fields, edge cases ('not found'), data source, and optional configuration. No output schema needed as return values are enumerated.
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 already describes the 'number' parameter, but description adds value by providing examples and clarifying that spaces/case are ignored, aiding correct invocation. Schema coverage is 100%, so baseline 3; extras justify 4.
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?
Clearly states the tool retrieves a UK company's official registered details by Companies House number, listing specific fields. Distinguishes from siblings (search and validate) by focusing on exact number lookup.
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 advises using this tool instead of relying on model recall, highlighting a key use case. Mentions limitations (monthly snapshot, dissolved companies absent) and optional API key for real-time data. Lacks explicit alternatives but context implies siblings for search/validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE THIS to find a UK company's number from its name (reverse lookup) instead of guessing the number — returns companies matching your search words from official Companies House data (the monthly snapshot by default, or the live register when a Companies House API key is set).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or keywords to search for. | |
| limit | No | Max results (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses data sources (monthly snapshot vs live register) and that it matches search words, but does not mention rate limits, pagination, or result structure.
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 sentence that front-loads the action. It is concise and contains no waste, though breaking it into two sentences could improve 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?
For a simple two-parameter tool with no output schema, the description covers purpose, data source, and key behavior. It could mention result format or multiple matches, but is fairly complete.
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% with descriptions for both parameters. The tool's description adds minor context about matching search words for the 'query' parameter, but does not significantly enhance 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 clearly states it finds a UK company's number from its name, using a reverse lookup. It distinguishes itself from sibling tools like lookup_company (presumably by number) and validate_company_number.
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 says 'USE THIS' and provides context (instead of guessing the number). It implies when to use but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE THIS to check a UK company number is well-formed and identify its register/type before relying on it — never assume 8 characters are valid. Checks the format (8 digits, or a 2-letter prefix + 6 digits; there is NO check digit) and returns what the prefix denotes (e.g. SC = Scotland, NI = Northern Ireland, OC = LLP). Does NOT confirm the company exists — use lookup_company for that.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The UK company number to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it only checks format, specifies valid patterns (8 digits or prefix+6 digits), notes there is no check digit, and explains what prefixes denote. Clearly states what it does not do (confirm existence).
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?
Two sentences, front-loaded with a strong imperative. Every sentence adds essential information with no waste.
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 validation tool with one parameter, no output schema, and clear sibling differentiation, the description covers purpose, usage guidelines, format details, and limitations completely.
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% (parameter 'number' has description), so baseline is 3. Description adds extra meaning by detailing valid formats and prefixes, going beyond the schema's simple description.
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 ('check'), identifies the resource ('UK company number'), and clearly states it validates format and identifies register/type. It distinguishes itself from lookup_company, which confirms existence.
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 states when to use ('before relying on it') and what not to use it for ('does NOT confirm the company exists'). References the sibling tool lookup_company as the alternative for existence checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0lookup_companysearch_companyvalidate_company_numberScored across 3 tools
Each tool has a clearly distinct and non-overlapping purpose: lookup by number, search by name, and validate number format. No ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (lookup_company, search_company, validate_company_number).
With 3 tools, the server is well-scoped for its narrow domain of UK company data lookup. Each tool serves an essential function without redundancy.
The tool set covers the complete workflow: search for a company to find its number, validate the number format, and retrieve official details. No obvious gaps.
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
UK company register lookups plus US, EU and UN sanctions screening. Every answer cites source.
Validate EU, UK, AU VAT numbers for AI agents. EU ViDA e-invoicing compliance.
Search UK companies, land registry prices, charities, OS locations, and traffic data
