This server resolves a company domain into the registered legal entity behind it, using Apify's Legal Entity Resolver actor.
resolve_legal_entity takes a company domain and returns legal name, company number, jurisdiction, status, entity type, LEI, and VAT number as one flat row.
Optionally skip domain lookup and search registers directly using legal_name_hint when you already know the legal name.
Narrow register searches by country with jurisdiction_hint (e.g., GB, US, FR, NO), or query all registers by leaving it empty.
Control match acceptance with match_strictness: exact (default) accepts only identical normalized legal names; fuzzy returns best-scoring candidates with warnings for research use.
Validate found VAT numbers through EU VIES with validate_vat to cross-check the register name.
Bypass or use cached results via skipCache: resolved companies cached 90 days, null results 7 days.
Receive full audit trail via match_method, match_confidence, and rejected_candidates before acting on a match.
Errors are surfaced explicitly for invalid input, bad tokens, exhausted balance, timeouts, or non-dataset runs — never silently swallowed.
Read-only operation: does not score or rate companies; it only answers which registered legal entity sits behind a domain.
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., "@mcp-legal-entity-resolver What's the legal entity behind monzo.com?"
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.
MCP server for the Mamba Labs Legal Entity Resolver actor on Apify.
Give it a company domain and it returns the registered legal entity behind it: legal name, company number, jurisdiction, status, LEI and VAT number. One flat row per domain, 24 fields, ready for Clay or a CRM.
npx -y @mambalabsdev/mcp-legal-entity-resolver{
"mcpServers": {
"mamba-legal-entity-resolver": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-legal-entity-resolver"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}Get an Apify token at console.apify.com/account/integrations.
Related MCP server: Workplace Program Detector MCP Server
resolve_legal_entityCompany domain in, the registered legal entity behind it out.
Input | Type | Required | Notes |
| string | yes | A single company domain, for example monzo.com. Protocol and path are stripped. |
| string | no | Skips the domain lookup and goes straight to the registers with this name. Use it when you already have the legal name and just want the register record. |
| string | no | ISO-2 country code. |
| enum | no |
|
| boolean | no | Runs any VAT number found on the company's own pages through the EU VIES service and returns the name VIES holds for it, as a cross-check against the register name. Default |
| enum | no |
|
Register search endpoints are fuzzy and they always return something. Taking the top search result gives you a confidently wrong company number more often than not. This actor accepts a match only when the legal names are identical after normalization, which is why roughly 6 domains in 10 resolve instead of 10 in 10, and why the 6 are worth acting on.
Read match_method, match_confidence and rejected_candidates before acting on a match. fuzzy strictness is a research mode: it will hand you a confidently wrong company on most domains.
Three registers are queried: UK Companies House, GLEIF and SEC EDGAR.
You are charged per domain resolved, plus the platform's actor start event. Prices from the live pricing record, read 2026-10-05:
Event | Price per event (USD) | Fires when |
| $0.007 on the Free plan, down to $0.00595 on higher Apify plans | One domain looked up: the company's own pages fetched and read for a legal name, then up to three company registers queried for an exact match. Charged whether or not a register matches, because the work is the same either way and charging only for matches would push this Actor toward guessing. Not charged when the domain cannot be reached at all. |
| $0.00005 | Charged when the Actor starts running. Number of events charged depends on Actor memory (one event per GB, minimum one event). |
Cached results are 90 days for a resolved company and 7 days for a null. The actor's Apify page carries the current prices. Running this server consumes Apify credits.
It is a thin client for the Apify actor. It passes your input through and returns the actor's output unchanged. Every behavior described above lives in the actor, not here.
This is not a company database and not a credit or risk product. It does not score companies, rate them, or tell you whether to trade with them. It answers one question: which registered legal entity sits behind this domain.
Errors are surfaced, never swallowed. An invalid input, an invalid token, an exhausted balance, a timeout, or a run that returns anything other than a dataset all come back as an explicit tool error rather than as an empty result.
Each call starts the actor run, polls it until it finishes, then reads the dataset. The run is allowed 1,800 seconds. If the run is still going when this call stops waiting, the call returns the run id and a console link instead of a timeout, so the result is never lost.
The actor is on the Apify Store. This wrapper is MIT licensed.
Built by Mamba Labs
Give it a company domain and it returns the registered legal entity behind it: legal name, company number, jurisdiction, status, entity type, LEI and VAT number, as one flat row with a full audit trail of what was rejected and why. Three registers are queried: UK Companies House, GLEIF and SEC EDGAR. Register search endpoints are fuzzy and always return something, so by default a record is accepted only when the normalized legal names are identical. That is why roughly 6 domains in 10 resolve rather than 10 in 10, and why a null here is a trustworthy answer rather than a gap. Read match_method, match_confidence and rejected_candidates before acting on a match. Setting match_strictness to fuzzy will hand you a confidently wrong company on most domains and should be treated as a research mode, not a default. This is not a company database and not a credit or risk product. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A single company domain, for example monzo.com. Protocol and path are stripped. | |
| skipCache | No | false uses the cache: 90 days for a resolved company, 7 days for a null. true forces a fresh look. Default: "false". | |
| validate_vat | No | Runs any VAT number found on the company's own pages through the EU VIES service and returns the name VIES holds for it, as a cross-check against the register name. Default: true. | |
| legal_name_hint | No | Skips the domain lookup and goes straight to the registers with this name. Use it when you already have the legal name and just want the register record. | |
| match_strictness | No | exact accepts a register record only when the normalized legal names are equal, which is the default and the recommendation. fuzzy returns the best scoring candidate with a confidence below 100 and a warning in rejected_candidates. Register search is fuzzy and always returns something, so fuzzy mode will hand you a confidently wrong company on most domains. Default: "exact". | |
| jurisdiction_hint | No | ISO-2 country code, for example GB or US. Narrows which registers are queried and cuts latency. Leave empty to query every register. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description significantly expands on the annotations. Annotations only state readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds key behavioral details: 'Register search endpoints are fuzzy and always return something,' 'a record is accepted only when the normalized legal names are identical,' and the resulting resolution rate ('roughly 6 domains in 10 resolve'). It also discloses credit consumption, which is not in the annotations. This provides a thorough behavioral profile beyond the structured fields.
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 longer than average but every sentence earns its place. It is front-loaded with the core purpose, then layers behavioral context, caveats, exclusions, and requirements. There is no fluff; even the redundancy about fuzzy mode emphasizes a critical warning. The structure is logical and easy to scan.
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 carries the full burden of explaining return values, and it does: it lists the returned fields (legal name, company number, jurisdiction, status, entity type, LEI, VAT number), the audit trail, and the match attributes. It also covers failure modes (null results), the reason behind them, and the registers queried. This is a complete picture for a tool of this complexity.
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%, so all six parameters are already well-documented in the schema. The description's mention of match_strictness and fuzzy mode largely repeats the schema's own warning ('fuzzy mode will hand you a confidently wrong company on most domains'). Since the schema already carries the heavy lifting and the description adds minimal additional parameter-level meaning, the baseline of 3 is appropriate.
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 the tool's purpose with a specific verb and resource: 'Give it a company domain and it returns the registered legal entity behind it: legal name, company number, jurisdiction, status, entity type, LEI and VAT number.' It also distinguishes itself from non-purposes by saying 'This is not a company database and not a credit or risk product.' Although there are no sibling tools to differentiate from, this goes beyond a basic definition by listing exact output fields.
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 provides explicit usage guidance: it explains when to trust null results ('a null here is a trustworthy answer rather than a gap'), warns against using fuzzy mode in production ('should be treated as a research mode, not a default'), and tells users to 'Read match_method, match_confidence and rejected_candidates before acting on a match.' It also specifies prerequisites ('Requires an APIFY_TOKEN and consumes Apify credits') and excludes specific use cases, offering clear context and exclusions.
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.
v1.0.0resolve_legal_entityScored across 1 tool
With only one tool, there is no possibility of confusion or misselection. The tool's purpose is clearly defined and distinct.
The tool name 'resolve_legal_entity' follows a clear verb_noun pattern, which is consistent and predictable even as a single tool.
The server is highly specialized, and a single complex tool is reasonable for its narrow purpose. While slightly under the typical 3-15 range, the tool's depth justifies the count.
The tool provides a comprehensive resolution workflow with audit trail, matching controls, and clear output. For its stated domain, there are no obvious missing capabilities.
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
Remote MCP server to enrich company profiles with structured B2B data and confidence scores.
Apify MCP — run web-scraping Actors and fetch their dataset results.
Identity resolution MCP server for phone/email lookups across 31+ services. Global + India coverage.
