A
licenseA
qualityA
maintenanceMCP server for GLEIF LEI (Legal Entity Identifier) database access. Look up, validate, and search legal entities and their relationships in the global LEI system.
12
6
MIT
mcp-legal-entity-resolver
by mambalabsdev
Legal Entity Resolver MCP Server
MCP-Server für den Actor Legal Entity Resolver von Mamba Labs auf Apify.
Gib ihm eine Unternehmensdomain und er gibt die eingetragene juristische Person dahinter zurück: rechtlicher Name, Firmennummer, Gerichtsbarkeit, Status, LEI und USt-IdNr. Eine flache Zeile pro Domain, 24 Felder, bereit für Clay oder ein CRM.
Installation
npx -y @mambalabsdev/mcp-legal-entity-resolverClaude Desktop
{
"mcpServers": {
"mamba-legal-entity-resolver": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-legal-entity-resolver"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}Hole dir ein Apify-Token unter console.apify.com/account/integrations.
Related MCP server: enrich-company-mcp
Tool
resolve_legal_entity
Unternehmensdomain rein, eingetragene juristische Person dahinter raus.
Eingabe | Typ | Erforderlich | Hinweise |
| string | Ja | Eine einzelne Unternehmensdomain, zum Beispiel monzo.com. Protokoll und Pfad werden entfernt. |
| string | Nein | Überspringt die Domain-Suche und geht mit diesem Namen direkt zu den Registern. Verwende es, wenn du den rechtlichen Namen bereits hast und nur den Registereintrag möchtest. |
| string | Nein | ISO-2-Ländercode. |
| enum | Nein |
|
| boolean | Nein | Lässt jede auf den eigenen Seiten des Unternehmens gefundene USt-IdNr. durch den EU-VIES-Dienst laufen und gibt den Namen zurück, den VIES für sie führt, als Gegenprüfung zum Registernamen. Standard ist |
| enum | Nein |
|
Ein Null-Ergebnis ist das Produkt, keine Lücke
Die Such-Endpunkte der Register sind unscharf und geben immer etwas zurück. Nimmt man das oberste Suchergebnis, erhält man in den meisten Fällen eine mit hoher Konfidenz falsche Firmennummer. Dieser Actor akzeptiert einen Treffer nur, wenn die rechtlichen Namen nach der Normalisierung identisch sind. Deshalb führen etwa 6 von 10 Domains zu einem Treffer statt 10 von 10, und deshalb lohnt es sich, auf die 6 zu reagieren.
Lies match_method, match_confidence und rejected_candidates, bevor du auf einen Treffer hin handelst. Die Einstellung fuzzy ist ein Forschungsmodus: Sie liefert dir auf den meisten Domains ein mit hoher Konfidenz falsches Unternehmen.
Es werden drei Register abgefragt: UK Companies House, GLEIF und SEC EDGAR.
Abrechnung
Dir wird pro ermittelte Domain etwas berechnet, plus eine kleine Actor-Startgebühr. Cache-Ergebnisse gelten 90 Tage für ein ermitteltes Unternehmen und 7 Tage für ein Null-Ergebnis.
Die Preise stehen auf der Apify-Seite des Actors. Der Betrieb dieses Servers verbraucht Apify-Credits.
Was dieser Server tut und nicht tut
Er ist ein dünner Client für den Apify-Actor. Er reicht deine Eingabe durch und gibt die Ausgabe des Actors unverändert zurück. Jedes oben beschriebene Verhalten liegt im Actor, nicht hier.
Dies ist keine Unternehmensdatenbank und kein Kredit- oder Risikoprodukt. Es bewertet Unternehmen nicht, stuft sie nicht ein und sagt dir nicht, ob du mit ihnen Geschäfte machen solltest. Es beantwortet eine Frage: Welche eingetragene juristische Person steckt hinter dieser Domain.
Fehler werden sichtbar gemacht, nie verschluckt. Eine ungültige Eingabe, ein ungültiges Token, ein erschöpftes Guthaben, ein Timeout oder ein Lauf, der etwas anderes als einen Datensatz zurückgibt, wird immer als expliziter Tool-Fehler zurückgegeben, nie als leeres Ergebnis.
Quelle
Der Actor ist im Apify Store erhältlich. Dieser Wrapper ist MIT-lizenziert.
Erstellt von Mamba Labs.
Available Tools
1 toolresolve_legal_entityResolve Legal EntityARead-onlyIdempotent
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.
ParametersJSON Schema
| 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. |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
TDQS
A4.7/5.0
Disambiguation5/5
With only one tool, there is no possibility of confusion or misselection. The tool's purpose is clearly defined and distinct.
Naming Consistency5/5
The tool name 'resolve_legal_entity' follows a clear verb_noun pattern, which is consistent and predictable even as a single tool.
Tool Count4/5
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.
Completeness5/5
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.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
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.
Identity resolution MCP server for phone/email lookups across 31+ services. Global + India coverage.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceDomain -> company intelligence for AI agents. Look up company name, country, contacts, and social profiles from any MCP-compatible client.6MIT
- AlicenseAqualityCmaintenanceAn MCP server for domain intelligence — WHOIS, DNS records, SSL certificate inspection, SPF/DMARC validation, security-header audits, and blacklist/reputation checks, callable by AI agents. Powered by domainintel.app; runs server-side, no local setup.799MIT
- AlicenseAqualityBmaintenanceMCP server for the Mamba Labs People Finder & Email Verifier actor on Apify. Give it a company domain, name or LinkedIn URL and it returns the people at that company who match your role, seniority and department filters, each as a structured contact record with an optional verified business email.195MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-legal-entity-resolver'
If you have feedback or need assistance with the MCP directory API, please join our Discord server