New Company Registrations Feed MCP Server
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., "@New Company Registrations Feed MCP ServerList IT companies registered in the UK and Norway this week."
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.
New Company Registrations Feed MCP Server
An MCP server for the Mamba Labs New Company Registrations Feed actor on Apify. Give it a registration window, industry codes, activity words, or places. Each run reads four official business registers and returns one row per newly registered company.
What's Inside
Related MCP server: mcp-norwegian-companies
What it does
The actor reads UK Companies House (on your own free Companies House key), Norway Brreg, Finland PRH, and France BODACC company creation notices, keeps the companies registered in your window that match your filters, and returns one flat row per company: register number, name, legal form, registration day, industry codes with their description, activity text, registered address, share capital, and the website and domain when the register lists one. Sole traders are never returned, filtered entries are never billed, and when nothing matches one free row says why.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
Quick start
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-new-company-registrations-feed": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-new-company-registrations-feed"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The find_new_company_registrations tool appears.
Prerequisites
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as
APIFY_TOKEN. The server lists its tool without a token; a call needs one.
Example prompts
"List IT companies registered in the UK and Norway this week."
"Which new French companies registered in Paris or Lyon this week do software or IT consulting?"
"Find new restaurants and cafes registered in Finland and Norway in the last 30 days."
Tool
find_new_company_registrations. One tool. Example arguments:
{
"industry_codes": [
"62"
],
"registered_within_days": "7"
}Inputs
Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and booleans are sent as strings.
Input | Type | Description |
| array | Registers to read. Default all four. UK Companies House is read only when the server has COMPANIES_HOUSE_API_KEY set. |
| string | Registration window in days, 1 to 90, today included. Default 7. |
| array | Industry code prefixes such as 62, 70.2, or 56. France BODACC has no codes and is skipped when this is set. |
| array | Words in the activity text the register publishes, in its own language, for example logiciel (France) or programvare (Norway). |
| array | Words in the company name. |
| array | City or region names, or short postal code prefixes such as EC1 or 75. |
| string | Drop entries already marked dissolved, bankrupt, or in liquidation. Default true. |
| string | Company rows per run, newest first, up to 5000. Each company row is billed. Default 200. |
| string | Skip companies an earlier run with the same state_key returned. Default false. |
| string | Names the seen list for only_new. |
| string | Optional. The run stops before any row that would take its charges over this amount. |
Pricing
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.0035 | $0.003325 | $0.00315 | $0.002975 |
| $0.002 | $0.002 | $0.002 | $0.002 |
The no results row and companies skipped by only_new are free.
Your keys
Norway, Finland, and France need no key. For UK Companies House, set your own free Companies House REST API key as the COMPANIES_HOUSE_API_KEY environment variable of this server; it is sent with each run as the actor's companies_house_api_key input, which the actor marks secret and never stores. Without it the UK register is skipped and the run says so. Mamba Labs pays the platform and proxy costs of the run.
Full actor documentation
apify.com/mambalabs/new-company-registrations-feed
License
MIT. See LICENSE.
Available Tools
1 toolfind_new_company_registrationsFind newly registered companiesARead-only
Find companies newly registered in official business registers: UK Companies House (when the server has a COMPANIES_HOUSE_API_KEY), Norway Brreg, Finland PRH, and France BODACC company creation notices. Filter by registered_within_days, industry_codes (NACE based prefixes such as 62 or 70.2, which work across UK SIC 2007, Norway SN2007, and Finland TOL 2008; France has no codes and is skipped when they are set), activity_keywords (register activity text, France and Norway), name_keywords, and locations. Returns one row per company: register, country, company_number, company_name, registration_date, company_type, company_status, industry_codes, industry_description, activity_description, address, postal_code, city, region, website and domain when listed, share_capital, and register_url. Sole traders are never returned. When nothing matches, one free no_results row says why. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per company row returned plus a run start.
| Name | Required | Description | Default |
|---|---|---|---|
| only_new | No | Skip companies an earlier run with the same state_key returned. Default false. | |
| locations | No | City or region names, or short postal code prefixes such as EC1 or 75. | |
| registers | No | Registers to read. Default all four. UK Companies House is read only when the server has COMPANIES_HOUSE_API_KEY set. | |
| state_key | No | Names the seen list for only_new. | |
| active_only | No | Drop entries already marked dissolved, bankrupt, or in liquidation. Default true. | |
| max_companies | No | Company rows per run, newest first, up to 5000. Each company row is billed. Default 200. | |
| name_keywords | No | Words in the company name. | |
| industry_codes | No | Industry code prefixes such as 62, 70.2, or 56. France BODACC has no codes and is skipped when this is set. | |
| max_charge_usd | No | Optional. The run stops before any row that would take its charges over this amount. | |
| activity_keywords | No | Words in the activity text the register publishes, in its own language, for example logiciel (France) or programvare (Norway). | |
| registered_within_days | No | Registration window in days, 1 to 90, today included. Default 7. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent=false, non-destructive), it discloses that APIFY_TOKEN is required, that Apify bills per returned row plus a run start, that failures return an error with a run ID, that empty results yield a single no_results row, and how only_new/state_key dedup behaves. This is exactly the context annotations cannot carry.
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?
Dense but front-loaded: it opens with the core action and registers, then filters, then return shape, then billing/error behavior. Every sentence carries distinct information, though the long enumeration of return fields makes it heavier than strictly necessary.
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?
With no output schema, the description compensates by listing every returned field, and it covers error semantics, the no_results sentinel row, billing model, and auth requirements. For an 11-parameter, multi-register tool this is sufficient for correct invocation.
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, but the description adds genuine cross-parameter meaning: NACE prefixes (62, 70.2) work across UK SIC 2007, Norway SN2007, and Finland TOL 2008, and activity_keywords target register-published text in France and Norway specifically. It clarifies which registers each filter actually applies to.
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 names a specific verb+resource ('Find companies newly registered in official business registers') and enumerates the exact registers covered (UK Companies House, Norway Brreg, Finland PRH, France BODACC). An agent immediately understands the scope without opening the schema.
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 states concrete operating conditions: UK Companies House only reads when COMPANIES_HOUSE_API_KEY is set, France BODACC is skipped when industry_codes are set, and sole traders are never returned. There are no sibling tools to route against, so explicit alternatives are unnecessary, but there is no explicit 'use this when' framing.
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.
1 tool update
v1.0.0- First observed
find_new_company_registrations
Related MCP Connectors
Company search and enrichment from official business registers in 200+ countries.
Live data from 80+ official national company registries. Unmodified. For KYB and due diligence.
Verify a company exists: UK, EU VAT, GLEIF LEI, 8 registers, search filters, UK filing history
Find European company records with registry source and freshness information.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables comprehensive access to the Norwegian Business Registry API for querying company information, board members, subsidiaries, organizational data, and voluntary organizations. Provides real-time access to over 1 million registered Norwegian entities with detailed corporate structure and governance data.159 npm8MIT
- AlicenseNot gradedqualityDmaintenanceProvides access to Norway's official business registry for searching companies, looking up organizational details, and identifying company roles and sub-units. It utilizes data from Brønnøysundregistrene to enable detailed queries by industry, municipality, or organization number.8 npmMIT
- AlicenseNot gradedqualityDmaintenanceProvides access to the Finnish company registry (PRH/YTJ) to search for businesses and retrieve detailed information using Business IDs. It enables users to perform industry-specific searches and track recent company registrations through official government open data.7 npmMIT
- AlicenseAqualityBmaintenanceExposes 29 official business-registry actors as MCP tools for KYC/AML, beneficial-owner (UBO), credit-risk and adverse-media workflows across 11 jurisdictions (EU, US, UAE). Sourced via Apify; pay-per-result.386MIT