mcp-legal-entity-resolver
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_legal_entityA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.