This MCP server lets AI agents look up companies and LEIs worldwide via GLEIF open data, with bulk queries, optional parent info, and (per README) Czech, Polish, and EU VAT checks.
lookup_company: find best match by legal name, optionally with ISO-2 country, returning LEI, addresses, status, and parents.
lookup_lei: get full record for one 20-character LEI, including parents.
bulk_lookup: run up to 500 LEI or "Legal name | CC" queries in one call.
czech_company_check: Czech ARES lookup by IČO or name, optionally including persons.
poland_krs_extract: Polish KRS extract by KRS number only, optionally including persons or full extract.
eu_vat_check: check EU VAT numbers in VIES and optionally match GLEIF LEIs.
All tools are built for KYB, supplier, and counterparty checks, not lead lists; personal data requires a lawful GDPR purpose.
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., "@Global Company Check MCP Server look up the LEI for Spotify in Sweden"
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.
An MCP server (stdio) that lets AI agents look up companies and Legal Entity Identifiers (LEIs) worldwide. It calls the Global Company Check actor on Apify, which reads GLEIF open data (CC0).
Not affiliated with or endorsed by GLEIF, the Czech Ministry of Finance, the Polish Ministry of Justice or the European Commission. Data comes from their public sources (GLEIF CC0, ARES, KRS open API, VIES).
Tool | What it does |
| Best match for a legal name; add an ISO-2 country (e.g. |
| Full record for one 20-character LEI |
| Up to 500 queries: LEIs or |
| Czech ARES: IČO lookup or company name (actor) |
| Poland KRS extract by KRS number only (actor) |
| EU VAT number check in VIES + GLEIF LEI match (actor) |
The LEI tools take include_parents (default true) to add direct and ultimate parents.
All tools take up to 500 items per call. Built for KYB, supplier and counterparty checks, not lead lists.
include_persons returns personal data (board members): use only for a lawful purpose (GDPR).
Related MCP server: companies-house-mcp
Runs go to your own Apify account using your APIFY_TOKEN:
each actor: first 25 results free, then $0.03 per company found / counterparty checked. No result, no charge.
Get an Apify API token: https://console.apify.com/settings/integrations
Install: pip install company-check-mcp (or uvx company-check-mcp)
Add to your MCP client, e.g. Claude Desktop / Cursor:
{
"mcpServers": {
"company-check": {
"command": "uvx",
"args": ["company-check-mcp"],
"env": { "APIFY_TOKEN": "apify_api_..." }
}
}
}From source: pip install . then run company-check-mcp.
MIT. Made by Fieldnote Agents.
Look up up to 500 companies in one run. Each query is either an LEI ('549300TTCXZOGZM2EY83') or 'Legal name | CC' with an optional ISO-2 country ('Spotify AB | SE'). One result per query.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | ||
| include_parents | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose useful traits: a hard cap of 500 queries, one result per query, and the accepted query syntaxes. It does not cover what happens on partial failure, whether queries are matched sequentially or in parallel, or any rate/latency expectations, and include_parents behavior is left entirely opaque.
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?
Three tight sentences with no filler: the batch capability and its limit lead, followed by the input grammar and the output cardinality. Every clause carries information an agent needs to construct a call.
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?
An output schema exists, so return values need not be spelled out, and 'one result per query' is enough there. The gaps are the unexplained include_parents parameter and the absence of any routing signal versus lookup_company/lookup_lei, which an agent choosing among three similarly named tools would benefit from.
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 0%, so the description must compensate, and it does so well for 'queries' by specifying both accepted forms (raw LEI, or 'Legal name | CC' with optional ISO-2 country) and giving concrete examples. However, 'include_parents' (boolean, default true) is never explained, leaving one of two parameters undocumented anywhere.
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?
States a specific verb and resource ('look up companies') plus the defining batch scope ('up to 500 ... in one run'), which separates it from the single-entity siblings lookup_company and lookup_lei. It never names those siblings explicitly, so the differentiation is inferable rather than stated.
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 'up to 500 in one run' phrasing implies the tool is for batch lookups while the siblings handle single entities, but no when-to-use condition or alternative is named. There is no guidance on what to do for a single company or on failure behavior for partially invalid query lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a company by legal name in GLEIF open data. Optionally pass an ISO 3166-1 alpha-2 country code (e.g. 'SE', 'DE', 'US') for a much better match. Returns the best match with LEI, legal name, addresses, status and (optionally) parent companies.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| country | No | ||
| include_parents | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses two useful traits: only the 'best match' is returned (not all matches), and parent companies are only included optionally. It omits auth requirements, rate limits, and whether matching is exact or fuzzy — meaningful gaps for a no-annotation tool.
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?
Three sentences, no filler: what it does, the optional argument and its benefit, and what comes back. The purpose is front-loaded and the value of the country code is stated inline rather than buried.
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 low-complexity read-only lookup with an output schema present, the description need not describe return shapes, and it still summarizes them. The remaining gap is edge behavior — no-match handling and match-exactness — which an agent would need in practice.
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 0%, so the description must compensate, and it largely does: 'name' means legal name, 'country' is spelled out as ISO 3166-1 alpha-2 with concrete examples and a stated payoff ('much better match'), and '(optionally) parent companies' maps to include_parents. It never names include_parents directly, leaving that binding slightly implicit.
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?
States a specific verb and resource ('Find a company') plus the backing dataset ('GLEIF open data'), and the qualifier 'by legal name' implicitly separates it from lookup_lei (identifier-based) and bulk_lookup. It stops short of naming the siblings explicitly, so an agent must infer the boundary rather than read it.
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 clearly frames the use case (lookup by name) and advises passing a country code for a 'much better match', which is a real usage hint. However, it never says when to prefer lookup_lei or bulk_lookup, nor addresses name ambiguity or what to do if no match is found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one 20-character Legal Entity Identifier (LEI) from any country in GLEIF open data. Returns legal name, addresses, registration status and parents.
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | ||
| include_parents | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data source (GLEIF open data) and the returned fields, which implies a safe read, but says nothing about authentication, rate limits, or behavior when the LEI is unknown.
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?
Two tight sentences with no filler. The lookup scope and source are front-loaded, and the return fields follow immediately.
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?
An output schema exists, so listing return fields is somewhat redundant, and neither parameter is meaningfully documented. For a two-parameter lookup tool the description is adequate but leaves the neighbor-selection question and parameter semantics unaddressed.
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 0%, so the description must compensate. It adds a useful format constraint for the 'lei' parameter (20 characters) and implies 'include_parents' via the mention of parents, but never explains what the two parameters actually control or their defaults. Coverage of the boolean toggle is essentially absent.
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 gives a specific verb (look up) and resource (a single 20-character LEI), plus the data source (GLEIF open data). The word 'one' implicitly differentiates it from the bulk_lookup sibling, though neither sibling is named explicitly.
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?
There is no explicit guidance on when to choose this tool over lookup_company or bulk_lookup. The singular 'one' hints at single-record scope, but the agent is left to infer the boundary against the bulk and company alternatives.
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.
v0.1.0bulk_lookuplookup_companylookup_leiScored across 3 tools
The three tools split cleanly by input key: lookup_company takes a legal name, lookup_lei takes a single 20-char LEI, and bulk_lookup handles many queries. There is mild overlap since bulk_lookup accepts both LEI and 'name | CC' formats, but the single-vs-batch boundary is clear enough to guide selection.
All names are snake_case and start with a lookup verb, giving a predictable read (lookup_company, lookup_lei). The only minor deviation is bulk_lookup, which drops the 'lookup_' prefix for the batch variant, but it remains understandable.
Three tools is slightly lean but well-matched to a focused GLEIF data-access service: one per lookup mode (name, LEI, batch). Each tool earns its place without redundancy, though the surface is minimal.
Core GLEIF access is covered: name search, single-LEI resolution, and batch lookup, all returning status, addresses and parents. Minor gaps exist (e.g. no reverse/parent-tree traversal or pagination/filter options), but agents can work around these by chaining lookups.
Verify a company on GLEIF LEI and SEC EDGAR, screen sanctions. No key; quota-free data.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Company research for AI agents: contacts, tech stack, LEI, EU legal entities, SEC financials, jobs
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
