Summary: This server gives you one read-only tool, resolve_legal_entity, which answers a single question — which registered legal entity sits behind a given company domain — by querying company registers and returning one flat row of verified entity data.
Resolve a domain to a legal entity: pass a single domain (e.g. monzo.com, protocol and path stripped) and get back legal name, company number, jurisdiction, status, entity type, LEI and VAT number as one flat row (~24 fields) ready for Clay or a CRM.
Look up by legal name instead: use legal_name_hint to skip the domain lookup and go straight to the registers when you already know the legal name.
Target specific registers: jurisdiction_hint (ISO-2) routes to Companies House (GB/UK), SEC EDGAR (US), French Sirene (FR) or Norwegian Brreg (NO), each alongside GLEIF; any other code queries GLEIF alone, and leaving it empty queries all registers.
Choose match strictness: match_strictness defaults to exact (normalized names must be identical); fuzzy is a research mode that returns the best-scoring candidate but will often hand you a confidently wrong company.
Audit any match: read match_method, match_confidence and rejected_candidates before acting; a null result is a trustworthy answer, not a gap (~6 of 10 domains resolve).
Cross-check VAT: validate_vat (default true) runs VAT numbers found on the company's own pages through EU VIES and returns the name VIES holds.
Control caching: skipCache uses a 90-day cache for resolved companies and 7-day cache for nulls, or forces a fresh look.
Know the constraints: requires APIFY_TOKEN, consumes Apify credits (charged per domain resolved plus an actor-start event), is read-only, idempotent and non-destructive, surfaces errors explicitly rather than as empty results, and returns a run id plus console link if a run outlasts the wait window.
Note on the schema: the tool's inputSchema only lists domain as required and omits the sec_requester_name/sec_requester_email and max_charge_usd fields the README describes, so SEC-related requirements may be enforced by the underlying actor rather than by this schema.
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 | Your own name or your company's name, sent to the SEC. |
| string | yes | Your own working email, sent to the SEC with your name. |
| 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 |
|
| number | no | Optional spending cap for this call, in USD. The actor stops before any charge that would take the run past this amount and keeps every row already charged. |
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.
Why the SEC fields are required. The SEC requires every automated request to EDGAR to identify the requester by name and email, as a User-Agent of the form Name email@domain.tld (SEC: Accessing EDGAR data). The actor sends your sec_requester_name and sec_requester_email and never a default or shared identity. A call without both fails before any request, naming the two fields.
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. | |
| max_charge_usd | No | Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account. | |
| 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. GB or UK asks Companies House and GLEIF and returns a Companies House number. US asks GLEIF and SEC EDGAR. FR asks the French Sirene register and returns a SIREN. NO asks the Norwegian Brreg register and returns an organisasjonsnummer. Any other code asks GLEIF alone rather than guessing at a register with no adapter. Leave empty to query all five. Narrowing cuts latency, and registers_queried on the row records which were actually asked, so a null is never ambiguous. | |
| sec_requester_name | Yes | Required. Your own name or your company's name. The SEC requires every automated request to EDGAR to identify the requester by name and email, and the actor sends yours, never a default. | |
| sec_requester_email | Yes | Required. Your own working email address. Sent to the SEC with your name in the User-Agent of each EDGAR request, in the form the SEC asks for. Nothing else uses it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say readOnlyHint=false, which is surprisingly defensive for a lookup; the description resolves the ambiguity by stating 'Read only' and by disclosing that it consumes Apify credits and requires an APIFY_TOKEN. It goes well beyond annotations with the 6-in-10 resolution rate, the always-returns-something register behavior, the audit trail of rejections, and the fields to read before acting. This is rich behavioral context the structured fields do not 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?
The description is front-loaded with the core contract (domain in, flat row out) then layers warnings. It is dense but every sentence carries information; the only cost is that the match_method/match_confidence warning and the fuzzy warning slightly overlap.
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 9-parameter tool with no output schema, the description covers inputs, the return shape (flat row with named fields), failure semantics (nulls are meaningful), cost/auth requirements, and the caveats needed to invoke it correctly. Nothing essential is missing.
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 value beyond the schema: it explains why match_strictness=fuzzy produces confidently wrong results, the default cache semantics for skipCache, and how jurisdiction_hint trades coverage for latency. The legal_name_hint alternative path is only lightly touched.
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 states a precise verb+resource: given a domain, it returns the registered legal entity behind it, and it enumerates the returned fields. It also draws explicit negative boundaries ('not a company database and not a credit or risk product') that no sibling tool supplies. There are no siblings, but the purpose is unmistakable.
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 gives clear conditions for the main behavior choice: default exact matching vs fuzzy mode, and warns fuzzy is a research mode, not a default. It also explains the null-is-trustworthy framing. It stops short of stating prerequisites like when a legal_name_hint is preferable, but the core guidance is explicit.
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.4.0resolve_legal_entity6 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / jurisdiction_hint / descriptionPrevious value: -"ISO-2 country code, for example GB or US. Narrows which registers are queried and cuts latency. Leave empty to query every register."New value: +"ISO-2 country code. GB or UK asks Companies House and GLEIF and returns a Companies House number. US asks GLEIF and SEC EDGAR. FR asks the French Sirene register and returns a SIREN. NO asks the Norwegian Brreg register and returns an organisasjonsnummer. Any other code asks GLEIF alone rather than guessing at a register with no adapter. Leave empty to query all five. Narrowing cuts latency, and registers_queried on the row records which were actually asked, so a null is never ambiguous."Input schema / properties / max_charge_usdAdded value: +{
+ "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / sec_requester_emailAdded value: +{
+ "description": "Required. Your own working email address. Sent to the SEC with your name in the User-Agent of each EDGAR request, in the form the SEC asks for. Nothing else uses it.",
+ "format": "email",
+ "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+ "type": "string"
+}Input schema / properties / sec_requester_nameAdded value: +{
+ "description": "Required. Your own name or your company's name. The SEC requires every automated request to EDGAR to identify the requester by name and email, and the actor sends yours, never a default.",
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "domain"
-]New value: +[
+ "sec_requester_name",
+ "sec_requester_email",
+ "domain"
+]v1.0.0resolve_legal_entityScored across 1 tool
There is only one tool, so there is nothing to confuse it with. Its purpose (domain → registered legal entity) is stated unambiguously, including what it does not do (not a company database, not a risk product).
A single tool named resolve_legal_entity follows a clear verb_noun snake_case pattern. There is no competing convention to clash with it.
The server is deliberately scoped to one operation, and that operation is substantive (multi-register lookup with audit trail). Still, a single tool is thin for a server surface and forces any multi-domain or reverse-lookup workflow to be handled outside it.
The core read path is well covered: resolution, confidence/method metadata, rejected candidates, and multiple registers. Gaps are minor — no batch resolution of many domains and no reverse lookup (name/company number → domain), which an agent would have to loop around.
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.
Shopify, ATS jobs, RSS, WordPress and sitemap data through Apify's official MCP server.
Apify MCP — run web-scraping Actors and fetch their dataset results.
