MCP server providing AI agents with European company data — company search, corporate structures, VAT validation, sanctions screening, insolvency search, beneficial ownership, and EU economic statistics.
company_search — Search 2M+ companies worldwide by name, filter by country
company_by_lei — Look up company details by LEI code
company_by_register — Find company by trade register number (e.g. HRB)
company_structure — Get corporate structure: parent company + subsidiaries
validate_vat_number — Validate EU VAT numbers, get company name & address
search_insolvencies — Search company insolvencies/bankruptcies across EU countries
get_beneficial_owners — Look up beneficial ownership (EU Anti-Money Laundering Directive)
check_sanctions — Screen against EU/US/UN sanctions lists (90+ datasets via OpenSanctions)
eu_gdp — GDP for EU countries (in million EUR)
eu_unemployment — Monthly unemployment rates (seasonally adjusted)
eu_inflation — Monthly inflation rates (HICP)
eu_business_demography — Business births, deaths, and active enterprises
get_industry_statistics — Industry-level stats by NACE code (enterprises, turnover, employment)
Related MCP server: gleif-mcp-server
pip install eu-company-mcp-server.mcp.json:
{
"mcpServers": {
"eu-company": {
"type": "stdio",
"command": "python",
"args": ["-m", "src.server"]
}
}
}All APIs are free and require no API key:
API | Data |
GLEIF | Company search, LEI codes, corporate structures (2M+ entities) |
VIES | EU VAT number validation with company details |
Eurostat | GDP, unemployment, inflation, business demography, industry statistics |
OpenSanctions | EU/US/UN sanctions lists, beneficial ownership (90+ datasets) |
Insolvenzbekanntmachungen.de | German insolvency filings + EU E-Justice Portal links |
Due Diligence — Verify company identity, check corporate structure, search insolvencies
KYC (Know Your Customer) — Validate company registration, VAT, and beneficial owners
AML (Anti-Money Laundering) — Screen against sanctions lists, check ownership structures
Market Research — Compare EU economies, industry statistics by NACE code
Compliance — Verify VAT numbers, sanctions screening for cross-border transactions
Export Control — Check if trading partners are on EU/US/UN sanctions lists
Category | Servers |
🔗 Blockchain | |
🌍 Data | Weather · Germany · Agriculture · Space · Aviation · EU Companies |
🔒 Security | |
🤖 Agent Infra | Memory · Directory · Hub · Reputation |
🔬 Research |
MIT
Firma per LEI-Code abrufen (volle Details).
LEI = Legal Entity Identifier, 20-stelliger Code. Gibt alle verfügbaren Daten inkl. BIC-Codes und Events.
Args: lei: LEI-Code (z.B. "7LTWFZYICNSX8D621K86" für Deutsche Bank)
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses specific return content (BIC codes and Events) compensating for the missing output schema, though omits rate limits or auth requirements.
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?
Well-structured with clear header, acronym definition, return value disclosure, and Args section; every sentence delivers necessary information without bloat.
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?
Adequately complete for a single-parameter tool, successfully describing the expected output to compensate for the absent output schema.
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?
Excellent compensation for 0% schema description coverage by providing the 20-character format explanation and a concrete example with Deutsche Bank.
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?
Clearly states it retrieves company data by LEI code and defines LEI, though it could explicitly contrast with the register-based sibling tool.
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?
Implies usage through LEI explanation and 'full details' mention, but lacks explicit when/when-not guidance relative to company_search or company_by_register.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Firma per Handelsregisternummer suchen.
Args: register_number: Registernummer (z.B. "HRB 30000") country: Ländercode (Standard: DE)
| Name | Required | Description | Default |
|---|---|---|---|
| register_number | Yes | ||
| country | No | DE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks disclosure of error behavior, rate limits, or what data is returned.
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?
Brief and front-loaded; Args section is slightly informal but efficiently delivers missing schema metadata.
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?
Lacks output description (no output schema exists), leaving return format ambiguous despite simple parameter set.
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?
Provides crucial examples (HRB 30000) and default value notes missing from 0% schema coverage, compensating for undescribed parameters.
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 clear specific action (search by commercial register number) but doesn't explicitly differentiate from company_search or company_by_lei siblings.
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?
No guidance on when to use versus alternatives (company_search) or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Firmen in der GLEIF-Datenbank suchen (weltweit, 2M+ Einträge).
Findet Unternehmen nach Name mit LEI, Adresse, Registernummer, Rechtsform und Gründungsdatum. Perfekt für Due Diligence und KYC.
Args: name: Firmenname oder Suchbegriff (z.B. "Siemens", "Deutsche Bank") country: ISO-Ländercode (z.B. "DE", "FR", "US"). Leer = weltweit. limit: Max. Ergebnisse (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| country | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (GLEIF), coverage scope (2M+ entries), and return fields (LEI, address, register number) beyond empty annotations; omits rate limits.
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?
Well-structured with clear separation between capability description and Args documentation; efficiently front-loaded with no extraneous text.
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?
Given no output schema exists, description adequately covers returned data fields and use cases; sufficient for a simple 3-parameter search tool.
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?
Fully compensates for 0% schema description coverage by documenting all three parameters with examples (e.g., 'Siemens', 'DE') and constraints (1-50 results).
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?
Explicitly states it searches companies by name in the GLEIF database (2M+ entries worldwide), distinguishing it from siblings like company_by_lei and company_by_register.
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?
Specifies use cases (Due Diligence, KYC) but lacks explicit guidance on when to use sibling tools (e.g., company_by_lei) instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Konzernstruktur einer Firma abrufen (Mutter + Töchter).
Zeigt die direkte Muttergesellschaft, die oberste Konzernmutter und alle direkten Tochtergesellschaften.
Args: lei: LEI-Code der Firma limit: Max. Tochtergesellschaften (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses scope of returned data (direct vs ultimate parent, direct subsidiaries only) and valid range for limit (1-50) without contradicting annotations.
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?
Extremely concise, front-loaded with purpose, uses structured Args section efficiently with no extraneous text.
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?
Adequately describes return values (hierarchical entities) despite missing output schema; could clarify if subsidiaries are recursive or direct-only (though 'direkten' implies direct).
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?
Fully compensates for 0% schema description coverage by explaining LEI code purpose and limit constraints (max subsidiaries 1-50).
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?
Clearly states it retrieves corporate group structure (parents + subsidiaries) and distinguishes from simple company lookup siblings like company_by_lei.
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?
Implies usage by describing returned entities (direct/ultimate parents, subsidiaries) but lacks explicit when-to-use guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unternehmensdemografie: Gründungen, Schließungen, aktive Firmen.
Zeigt wie viele Unternehmen gegründet/geschlossen wurden. Quelle: Eurostat.
Args: countries: Ländercodes (z.B. "DE;FR;IT") year: Jahr (z.B. "2021")
| Name | Required | Description | Default |
|---|---|---|---|
| countries | No | DE;FR;IT;ES | |
| year | No | 2021 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Cites Eurostat as source but lacks details on return format, caching, rate limits, or authentication needs (no annotations provided to supplement).
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?
Compact and front-loaded; Args section efficiently conveys parameter semantics without verbosity.
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?
Adequate for simple 2-parameter tool but lacks description of return values (no output schema exists) and misses Title field.
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?
Effectively compensates for 0% schema description coverage by documenting both parameters with examples (semicolon-separated country codes, year format).
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?
Clearly states it retrieves Eurostat business demography data (foundations, closures, active firms) with specific metrics, though could emphasize 'aggregate statistics' to better distinguish from individual company lookup siblings.
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?
Provides no guidance on when to use this vs company_search (individual entities) or other Eurostat tools like eu_gdp.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BIP (Bruttoinlandsprodukt) für EU-Länder abrufen.
Quelle: Eurostat. Werte in Millionen Euro.
Args: countries: Ländercodes mit Semikolon getrennt (z.B. "DE;FR;IT") years: Jahre mit Semikolon getrennt (z.B. "2022;2023")
| Name | Required | Description | Default |
|---|---|---|---|
| countries | No | DE;FR;IT;ES | |
| years | No | 2022;2023 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (Eurostat) and units (Millions of Euros), but lacks information on error handling, rate limits, or data freshness.
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?
Well-structured with purpose front-loaded, followed by metadata and Args section; appropriately concise without redundancy.
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?
Adequate for the tool's low complexity (2 simple parameters, no output schema), covering essential usage context despite missing return value description.
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?
Excellent compensation for 0% schema coverage by detailing delimiter format (semicolon-separated) and providing concrete examples for both parameters.
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?
Clearly states it retrieves GDP (BIP) for EU countries with specific verb and resource, distinguishing it from sibling economic indicators like eu_inflation and eu_unemployment.
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?
Provides no explicit guidance on when to use versus alternatives, or limitations like data availability lags for recent years.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inflationsrate (HICP) für EU-Länder.
Args: countries: Ländercodes (z.B. "DE;FR") periods: Monate im Format YYYY-MM (z.B. "2025-01;2025-06")
| Name | Required | Description | Default |
|---|---|---|---|
| countries | No | DE;FR;IT;ES | |
| periods | No | 2025-01 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose behavioral traits like idempotency, rate limits, or data freshness.
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?
Appropriately brief and well-structured with purpose front-loaded and clear Args section, though slightly terse.
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?
Adequate for a simple lookup tool but lacks description of return values or output format given no output schema exists.
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?
Effectively compensates for 0% schema description coverage by explaining both parameters with format examples (semicolon-delimited codes and YYYY-MM periods).
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?
Clearly states it retrieves HICP inflation rates for EU countries, distinguishing it from siblings like eu_gdp and eu_unemployment through specific subject matter.
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?
Provides no guidance on when to use this tool versus alternative economic data tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arbeitslosenquote für EU-Länder (monatlich, saisonbereinigt).
Args: countries: Ländercodes (z.B. "DE;FR;IT") periods: Monate im Format YYYY-MM (z.B. "2025-01;2025-06")
| Name | Required | Description | Default |
|---|---|---|---|
| countries | No | DE;FR;IT;ES | |
| periods | No | 2025-01 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key data characteristics (monthly, seasonally adjusted) but lacks information on rate limits, caching, or error behaviors that annotations don't cover.
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?
Extremely concise with purpose front-loaded in first sentence; Args section efficiently documents parameters without redundancy.
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?
Adequate for simple 2-parameter tool but omits return value description needed due to missing output schema; doesn't specify data source or units.
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?
Excellent compensation for 0% schema coverage by providing detailed Args section with format specifications ('Ländercodes', 'YYYY-MM') and concrete semicolon-separated examples.
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?
Clearly states it retrieves unemployment rates ('Arbeitslosenquote') for EU countries with monthly seasonally-adjusted data, distinguishing it from siblings like eu_gdp or eu_inflation.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., eu_business_demography) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EU-Umsatzsteuer-ID (USt-ID / VAT) überprüfen.
Prüft ob eine USt-ID gültig ist und gibt (falls verfügbar) Firmenname und Adresse zurück. Quelle: EU VIES System.
Hinweis: Deutschland gibt nie Name/Adresse zurück. Die meisten anderen EU-Länder liefern Details.
Args: country_code: 2-Buchstaben Ländercode (z.B. "DE", "FR", "IT", "NL") vat_number: USt-ID Nummer ohne Länderprefix (z.B. "811128135")
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| vat_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral limitation (Germany never returns name/address, others do) and data source, though lacks rate limit or auth details.
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?
Well-structured with purpose front-loaded; Args section is clearly delineated, though labels like 'Hinweis:' and 'Quelle:' add slight verbosity.
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?
Adequately covers expected return values (validity status, optional name/address) and limitations despite absence of output schema.
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?
Excellent compensation for 0% schema coverage: provides clear format specifications and concrete examples for both parameters (especially the no-prefix requirement for vat_number).
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?
Clear specific purpose (validate EU VAT IDs) with resource identification (EU VIES System) and distinguishes from company lookup siblings.
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?
Usage is implied through functionality description (validating VAT IDs), but lacks explicit when-not-to-use guidance or comparison to company search alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: four different company lookup methods (by LEI, register number, name search, VAT validation), one corporate structure tool, and four distinct EU macroeconomic indicators (GDP, inflation, unemployment, business demography). No functional overlap exists between the identifier-based lookups or the economic data tools.
While consistently using snake_case, the toolset mixes multiple naming conventions: company lookup tools use 'company_by_*' for two tools but 'company_search' and 'company_structure' for others, while 'validate_vat_number' breaks the pattern entirely with verb-first syntax. The EU economic tools consistently use the 'eu_' prefix, but the overall set lacks a unified verb-noun or noun-first convention.
The nine tools represent a well-scoped balance between company identification capabilities (five tools covering major identifiers) and EU economic context (four tools for key indicators). Each tool addresses a specific use case without redundancy, making the count ideal for an EU business intelligence server focused on lookup and macro data.
The surface covers primary company identification methods (LEI, VAT, register number, name search) and essential EU economic indicators, but minor integration gaps exist between tools—for example, VAT validation does not explicitly return LEI codes needed for structure lookups, requiring agents to chain name-based searches. Additional company lifecycle data like officer listings or historical financials are absent but not critical for the core lookup purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
11.3M entities, 10 countries, 12 tools. EU VAT (VIES), BORME, GLEIF, KYB. Free: 100 req/month.
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Swiss customs (TARES), FINMA registry & NOGA/NACE/ISIC classifications. 9 MCP tools, free tier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/eu-company-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
