de en es ja ko ru zh

ENTIA Entity Verification

Name: ENTIA Entity Verification
Author: ENTIA-IA

Official

by ENTIA-IA

Overview Schema Source Related Servers Discussions Admin

Python

Remote

ENTIA MCP Server

Strukturierte Geschäftsinformationen für KI-Agenten.

ENTIA bietet verifizierte Unternehmensdaten aus 10 Ländern – zugänglich über Model Context Protocol (MCP) oder REST-API.

Metrik	Wert
Verifizierte Entitäten	11,330,392
Länder	10
BORME-Handelsregistereinträge	40.3M
Gesundheitsfachkräfte	570K+
MCP-Tools	12
REST-Endpunkte	4

Schnellstart (< 2 Minuten)

Option 1: Remote-MCP-Server (empfohlen)

Keine Installation erforderlich. Verbinden Sie Ihren MCP-Client direkt:

Claude Desktop – fügen Sie Folgendes zu claude_desktop_config.json hinzu:

{
  "mcpServers": {
    "entia": {
      "command": "npx",
      "args": ["mcp-remote", "https://mcp.entia.systems/mcp"]
    }
  }
}

Cursor IDE – fügen Sie Folgendes zu .cursor/mcp.json hinzu:

{
  "mcpServers": {
    "entia": {
      "command": "npx",
      "args": ["mcp-remote", "https://mcp.entia.systems/mcp"]
    }
  }
}

Dann versuchen Sie:

Look up Telefonica in Spain

Option 2: REST-API

# Search entities
curl "https://entia.systems/v1/search?q=telefonica&country=ES&limit=5" \
  -H "X-ENTIA-Key: YOUR_API_KEY"

# Full entity profile (BORME + GLEIF + VIES + Wikidata)
curl "https://entia.systems/v1/profile/Telefonica?country=ES"

# EU VAT verification
curl "https://entia.systems/v1/verify/vat/ESA28015865"

# Platform stats
curl "https://entia.systems/v1/stats"

Option 3: Python-Client (in diesem Repository)

Ein Python-Client befindet sich in diesem Repository unter entia_mcp/ (kapselt eine Teilmenge der Tools als Komfortmethoden). Die vollständige 12-Tool-Oberfläche ist jederzeit über den gehosteten Endpunkt (Option 1) verfügbar. Ein veröffentlichtes PyPI-Paket ist geplant.

Related MCP server: Bizfile MCP

12 MCP-Tools

Tool	Funktion
`entity_lookup`	Identität eines beliebigen Unternehmens anhand von Name, CIF/NIF, EU-USt-IdNr. oder LEI verifizieren. Kreuzprüfung mit BORME, VIES, GLEIF.
`search_entities`	Verifizierte Entitäten in 10 Ländern nach Name, Stichwort, Land oder Branche durchsuchen.
`verify_vat`	Echtzeit-Validierung der EU-USt-IdNr. über VIES (27 Mitgliedstaaten).
`zone_profile`	Spanisches sozioökonomisches Profil nach Postleitzahl (INE/SEPE/AEAT): Einkommen, Beschäftigung, Unternehmensdichte.
`get_competitors`	Echte Wettbewerber im selben Sektor und derselben Geografie.
`get_showcase`	Kuratierte IBEX35- und EU-Showcase-Entitäten. Kostenlos, verbraucht kein Kontingent.
`professional_lookup`	Berufsregistrierungen in 24 spanischen Gesundheits-, Rechts- und Psychologie-Bereichen verifizieren. Erfordert DPA (DSGVO Art. 28).
`get_full_dossier`	Aggregator: 90+ Felder zu einer Entität in einem Aufruf (kombiniert 4 ENTIA-Quellen).
`get_platform_stats`	Live-Plattformstatistiken: Entitäten, Länder, Quellen.
`run_risk_audit`	KI-Bereitschafts- und digitales Risikoaudit für jede Domain.
`get_entia_home`	Vollständiger Schema.org JSON-LD @graph für eine Entität (Entia Home).
`get_entity_home_projection`	Maschinenlesbare Projektion eines Entia-Home-Datensatzes (v1).

Preise

Kostenlose Stufe: 100 Anfragen/Monat. Die maßgeblichen Preise werden live unter entia.systems/.well-known/ai-pricing.json veröffentlicht.

Stufe	Preis	Anfragen	Mehrverbrauch
TRACE	Kostenlos	100/Monat	Harte Sperre
SIGNAL	29 EUR/Monat	500/Monat	Harte Sperre
BUILD	99 EUR/Monat	2.500/Monat	Harte Sperre
INTEGRATE	399 EUR/Monat	10.000/Monat	0,15 EUR/Anfrage
OPERATE	1.499 EUR/Monat	100.000/Monat	0,10 EUR/Anfrage
SCALE	2.500+ EUR/Monat	500.000/Monat	0,05 EUR/Anfrage (Kontakt)
ENTERPRISE	Individuell	Unbegrenzt	—

Holen Sie sich Ihren API-Schlüssel: entia.systems/mcp-setup

Datenquellen

Alle Daten stammen aus offiziellen öffentlichen Registern:

BORME – Spanisches Handelsregister (BOE)
VIES – EU-USt-IdNr.-Validierung (Europäische Kommission)
GLEIF – Rechtsträgerkennungen (Global LEI Foundation)
Wikidata – Wissensgraph (Wikimedia Foundation)
REPS – Spanisches Register für Gesundheitsfachkräfte
INE – Spanisches Nationales Statistikinstitut
SEPE – Spanischer Arbeitsvermittlungsdienst
AEAT – Spanische Steuerbehörde
Companies House – Britisches Unternehmensregister
Sirene/INSEE – Französisches Unternehmensregister

Über

Erstellt von PrecisionAI Marketing OU (Estland, EU).

USt-IdNr.: EE102780516
DUNS: 565868914
e-Residency-zertifiziert
eIDAS-konform

Lizenz

Code: MIT (siehe LICENSE). Dieser Server ist ein schlanker MCP-Wrapper: Er spricht JSON-RPC und leitet an die ENTIA-API weiter. Den Wrapper offen zu halten ist beabsichtigt – so kann jeder Client genau prüfen, was gesendet und zurückgegeben wird.

Daten: proprietär – MIT gilt nicht für sie. Der über diesen Server erreichbare Korpus verifizierter Entitäten ist separat lizenziert und der Zugriff wird über API-Schlüssel kontrolliert. Die Nutzung der Daten unterliegt dem Data Licensing Framework, den MCP-Bedingungen und den Nutzungsbedingungen und ist durch das sui-generis-Datenbankrecht (Richtlinie 96/9/EG) geschützt. Das Klonen dieses Repositorys gewährt keinerlei Rechte an dem Korpus.

Available Tools

6 tools

borme_lookupAInspect

Spanish mercantile acts from BORME (40M+ acts, 2009-2026).

Use when: user asks "who founded X?", "when was X incorporated?", "directors of Santander", "corporate history of Inditex". Returns: Acts count, key officers, founding date, corporate events.

Examples: borme_lookup("Telefonica") → 17,320 acts borme_lookup("A28015865") → Telefonica by CIF borme_lookup("Santander") → 50,722 acts

Args: query: Company name or Spanish CIF (without ES prefix, e.g. A28015865)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description reveals key behavioral details: it covers 40M+ acts from 2009-2026, returns act count, key officers, founding date, and events. It also specifies the query format (CIF without ES prefix). This is transparent, though it could mention 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured with line breaks for examples, and uses front-loaded purpose. Every sentence adds value; no redundancy.

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?

Given the output schema exists (context signals), the description adequately covers input format, output summary (acts count, officers, events), and scope. It is complete for this simple tool with one parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'query' has no schema description (0% coverage), but the description compensates fully by explaining it can be a company name or Spanish CIF without the ES prefix, with an example. This adds critical meaning beyond the schema.

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 that the tool looks up Spanish mercantile acts from BORME, providing specific use cases like 'who founded X?' and examples. It effectively distinguishes itself from sibling tools (e.g., entity_lookup, verify_vat) by focusing on BORME records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit usage triggers (e.g., 'when user asks...') and example queries, which is clear guidance. However, it lacks explicit when-not-to-use or alternative tools, so it is not a perfect 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

entity_lookupAInspect

Verify the identity of any business across 34 countries.

Use when: user asks "is this company legit?", "check CIF B80988678", "verify Telefonica". Returns: Trust Score 0-100, BORME acts count, LEI, Wikidata QID, jurisdiction.

Example: entity_lookup("Telefonica")

Args: query: Company name (Telefonica), CIF (A28015865), EU VAT (ESA28015865), or LEI (20 chars)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses return fields and accepted input formats, but does not mention safety, authentication needs, or error behavior. It adds some value beyond schema but lacks depth for a no-annotation scenario.

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 concise (6 lines) and well-structured: purpose, usage conditions, return fields, example, and parameter description. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single parameter and presence of an output schema, the description covers input/output adequately and provides usage context. However, it lacks details on error handling or not-found cases, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by detailing the 'query' parameter: it accepts company name, CIF, EU VAT, or LEI, with examples. This is essential for correct invocation.

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 verb 'Verify' and resource 'business identity' across 34 countries. It distinguishes itself from siblings like borme_lookup (BORME acts) and verify_vat (VAT) by focusing on identity verification with multiple identifiers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use when' with concrete user queries ('is this company legit?', 'check CIF B80988678'), giving clear context. While it doesn't explicitly state when not to use, the examples and sibling names imply alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_competitorsAInspect

Find competitors in the same sector and city.

Use when: user asks "who are the competitors?", "other dental clinics in Madrid", "similar businesses in Barcelona". Returns: Verified competitors with name, phone, website, address.

Examples: get_competitors("dental", "Madrid") get_competitors("legal", "Barcelona", limit=5)

Args: sector: Sector slug (dental, legal, reformas, estetica, veterinarios, asesorias, talleres, inmobiliarias, restaurantes, psicologia, gimnasios...) city: City name (Madrid, Barcelona, Valencia, Sevilla, Zaragoza...) country: ISO country code. Default: ES limit: Max results 1-50. Default: 10

ParametersJSON Schema

Name	Required	Default
`sector`	Yes
`city`	Yes
`country`	No	ES
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states it returns 'Verified competitors with name, phone, website, address,' implying a read-only operation. While it doesn't detail authorization or rate limits, the behavior is sufficiently disclosed for a simple search tool.

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 concise, well-structured with sections for usage, returns, and examples. Every sentence is meaningful, and there is no redundant information.

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?

Given the tool's simplicity, the description provides complete context: purpose, usage triggers, return format, and parameter details. The presence of an output schema reduces the need to explain return values, though the description already covers them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by listing each parameter with examples, valid values (e.g., sector slugs, city names), defaults, and ranges. This adds significant meaning beyond the input schema.

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 'Find competitors in the same sector and city,' providing a specific verb, resource, and scope. It distinguishes itself from sibling tools like borme_lookup or verify_vat, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the tool with user query examples ('who are the competitors?'), but does not mention when not to use it or contrast with siblings. However, the context is clear enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_entitiesAInspect

Browse the entity registry by name, sector, or city.

Use when: user asks "find me a dentist in Madrid", "list lawyers in Barcelona", "show me car repair shops in Valencia". Returns: Verified entities with name, phone, website, address, sector.

Example: search_entities(q="dental", city="Madrid", limit=5)

Args: q: Search query — company name or keyword (dental, abogado, taller...) country: ISO country code (ES, GB, FR, DE, ...). Default: ES sector: Sector slug (dental, legal, reformas, estetica, veterinarios, asesorias...) city: City name (Madrid, Barcelona, Valencia, Sevilla...) limit: Max results 1-50. Default: 10

ParametersJSON Schema

Name	Required	Default
`q`	Yes
`country`	No	ES
`sector`	No
`city`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description reveals that the tool returns verified entities and lists the fields. It could further disclose any rate limits, authentication requirements, or pagination behavior, but the provided details are adequate for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for when to use, returns, and parameters. It is informative but slightly lengthy; a more concise wording could improve readability.

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?

Given the tool's complexity (5 parameters, no annotations, output schema exists), the description covers purpose, usage, parameters, and return fields comprehensively. It addresses all key aspects an agent needs to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage, but the description compensates fully by explaining each parameter: q, country (with default ES), sector (with examples), city, and limit (with range). It adds value beyond the schema by providing context and defaults.

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 browses the entity registry by name, sector, or city, and provides concrete examples like 'find me a dentist in Madrid'. It distinguishes itself from sibling tools (e.g., entity_lookup) by focusing on broad search rather than specific lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly specifies when to use the tool with example user queries. However, it does not explicitly state when not to use it or contrast with sibling tools like entity_lookup, which would help an agent decide between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_vatAInspect

Verify an EU VAT number via VIES (live, 27 member states, sub-second).

Use when: user asks "is this VAT valid?", "verify ESA28015865", "is this EU company registered?". Returns: valid (bool), legal name, registered address, country.

Examples: verify_vat("ESA28015865") → Telefonica SA — valid verify_vat("FR12345678901") → French company VAT check

Args: vat_id: Full EU VAT with country prefix (ESA28015865, FR12345678901, DE123456789)

ParametersJSON Schema

Name	Required	Description	Default
`vat_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It describes real-time live check, speed (sub-second), and return fields (valid, legal name, address, country). Lacks details on rate limits or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose, usage, returns, and args. Some redundancy (examples repeated), but overall efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter and an output schema (implied), description explains return values adequately. Could mention VIES availability, but sufficient for a simple verification tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, vat_id, with description explaining required format (country prefix, examples). Schema coverage is 0%, so description fully compensates with format and examples.

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 verifies EU VAT numbers via VIES, with specific verb and resource, and distinguishes from sibling tools like borme_lookup and entity_lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use: when user asks about VAT validity, verification, or EU company registration. Provides examples but does not explicitly mention when not to use, though context implies it's VAT-specific.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

zone_profileAInspect

Spanish socioeconomic data by postal code (INE/SEPE/AEAT/MITMA/MITECO).

Use when: user asks "what's the income level in 28001?", "unemployment rate in this area", "demographics of 08001 Barcelona". Returns: Median income (AEAT), unemployment (SEPE), population (INE), property price €/m² (MITMA), broadband coverage (MITECO).

Examples: zone_profile("28001") → Madrid Salamanca: income €99K, FTTH 99% zone_profile("08001") → Barcelona Eixample zone_profile("41001") → Sevilla Centro

Args: postal_code: Spanish 5-digit postal code (28001, 08001, 41001...)

ParametersJSON Schema

Name	Required	Description	Default
`postal_code`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior4/5

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 sources and types of data returned. While it doesn't explicitly mention read-only behavior, rate limits, or data freshness, it is sufficiently transparent for a straightforward data retrieval tool.

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 well-structured with clear sections (purpose, use when, returns, examples, args). Every sentence adds value, and the key information is front-loaded.

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?

Given the tool's simplicity (1 parameter, no nested objects, straightforward output), the description covers all needed aspects: what it does, when to use, input format, and output contents. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% but the description compensates fully by describing the only parameter 'postal_code' with format ('Spanish 5-digit postal code') and examples ('28001, 08001, 41001...'). This adds essential context beyond the schema's title and type.

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 explicitly states 'Spanish socioeconomic data by postal code' and lists specific data sources (INE/SEPE/AEAT/MITMA/MITECO) and metrics (income, unemployment, etc.). It clearly distinguishes from sibling tools (e.g., entity_lookup, borme_lookup) which target different domains.

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 'Use when' guidance with examples of user queries, and includes example inputs and outputs. This clearly indicates when the tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

20 tool updatesMay 3, 2026
- Changedborme_lookup6 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / limit
```
Removed value: -{
-  "default": 20,
-  "description": "Max mercantile acts to return (1-50)",
-  "maximum": 50,
-  "minimum": 1,
-  "type": "integer"
-}
```
  - removedInput schema / properties / query / description
```
Removed value: -"Spanish CIF (e.g. B80988678) or company name"
```
  - addedInput schema / properties / query / title
```
Added value: +"Query"
```
  - addedInput schema / title
```
Added value: +"borme_lookupArguments"
```
  - addedOutput schema / title
```
Added value: +"borme_lookupDictOutput"
```
- Removedborme_new_constitutions
- Removedborme_officer_changes
- Changedentity_lookup6 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / country
```
Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "ISO country code (ES, GB, FR...). Auto-detected from VAT prefix if not provided"
-}
```
  - removedInput schema / properties / query / description
```
Removed value: -"CIF (e.g. B80988678), EU VAT (e.g. ESB80988678, FR12345678901), LEI (20 alphanumeric chars), or company name"
```
  - addedInput schema / properties / query / title
```
Added value: +"Query"
```
  - addedInput schema / title
```
Added value: +"entity_lookupArguments"
```
  - addedOutput schema / title
```
Added value: +"entity_lookupDictOutput"
```
- Changedget_competitors13 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / city / description
```
Removed value: -"City name (e.g. Madrid, Barcelona)"
```
  - addedInput schema / properties / city / title
```
Added value: +"City"
```
  - removedInput schema / properties / country / description
```
Removed value: -"ISO country code"
```
  - addedInput schema / properties / country / title
```
Added value: +"Country"
```
  - removedInput schema / properties / limit / description
```
Removed value: -"Max results (1-30)"
```
  - removedInput schema / properties / limit / maximum
```
Removed value: -30
```
  - removedInput schema / properties / limit / minimum
```
Removed value: -1
```
  - addedInput schema / properties / limit / title
```
Added value: +"Limit"
```
  - removedInput schema / properties / sector / description
```
Removed value: -"Business sector: dental, legal, estetica, psicologia, talleres, veterinarios, reformas, inmobiliarias, asesorias, gimnasios..."
```
  - addedInput schema / properties / sector / title
```
Added value: +"Sector"
```
  - addedInput schema / title
```
Added value: +"get_competitorsArguments"
```
  - addedOutput schema / title
```
Added value: +"get_competitorsDictOutput"
```
- Removedget_entity_home
- Removedget_platform_stats
- Removedmunicipality_profile
- Removedprofessional_lookup
- Removedsearch_dental_clinics_cataluna
- Changedsearch_entities15 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / city / description
```
Removed value: -"City name (e.g. Madrid, Barcelona, London)"
```
  - addedInput schema / properties / city / title
```
Added value: +"City"
```
  - removedInput schema / properties / country / description
```
Removed value: -"ISO country code"
```
  - addedInput schema / properties / country / title
```
Added value: +"Country"
```
  - removedInput schema / properties / limit / description
```
Removed value: -"Max results (1-50)"
```
  - removedInput schema / properties / limit / maximum
```
Removed value: -50
```
  - removedInput schema / properties / limit / minimum
```
Removed value: -1
```
  - addedInput schema / properties / limit / title
```
Added value: +"Limit"
```
  - removedInput schema / properties / q / description
```
Removed value: -"Company name or partial name to search"
```
  - addedInput schema / properties / q / title
```
Added value: +"Q"
```
  - removedInput schema / properties / sector / description
```
Removed value: -"Business sector filter: dental, legal, estetica, psicologia, talleres, veterinarios, reformas, inmobiliarias, asesorias, gimnasios..."
```
  - addedInput schema / properties / sector / title
```
Added value: +"Sector"
```
  - addedInput schema / title
```
Added value: +"search_entitiesArguments"
```
  - addedOutput schema / title
```
Added value: +"search_entitiesDictOutput"
```
- Removedsearch_healthcare_centers
- Removedsearch_pharmacies
- Removedsearch_regcess
- Removedsearch_reps_by_specialty
- Removedverify_dentist
- Removedverify_healthcare_professional
- Removedverify_psychologist
- Changedverify_vat5 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / vat_id / description
```
Removed value: -"EU VAT number with country prefix (e.g. ESB80988678, FR12345678901, DE123456789)"
```
  - addedInput schema / properties / vat_id / title
```
Added value: +"Vat Id"
```
  - addedInput schema / title
```
Added value: +"verify_vatArguments"
```
  - addedOutput schema / title
```
Added value: +"verify_vatDictOutput"
```
- Changedzone_profile5 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / postal_code / description
```
Removed value: -"Spanish postal code (5 digits, e.g. 28001, 08001, 41001)"
```
  - addedInput schema / properties / postal_code / title
```
Added value: +"Postal Code"
```
  - addedInput schema / title
```
Added value: +"zone_profileArguments"
```
  - addedOutput schema / title
```
Added value: +"zone_profileDictOutput"
```
20 tool updatesv0.1.0Apr 13, 2026
- First observedborme_lookup
- First observedborme_new_constitutions
- First observedborme_officer_changes
- First observedentity_lookup
- First observedget_competitors
- First observedget_entity_home
- First observedget_platform_stats
- First observedmunicipality_profile
- First observedprofessional_lookup
- First observedsearch_dental_clinics_cataluna
- First observedsearch_entities
- First observedsearch_healthcare_centers
- First observedsearch_pharmacies
- First observedsearch_regcess
- First observedsearch_reps_by_specialty
- First observedverify_dentist
- First observedverify_healthcare_professional
- First observedverify_psychologist
- First observedverify_vat
- First observedzone_profile

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-05-03 07:25 across 6 tools

Disambiguation4/5

Tools have mostly distinct purposes. `borme_lookup` focuses on Spanish mercantile acts, while `entity_lookup` provides broader verification across 34 countries. `get_competitors` and `search_entities` both search for businesses but with different focuses (competitors vs. general registry). `verify_vat` and `zone_profile` are clearly distinct.

Naming Consistency5/5

All tool names follow a consistent `verb_noun` pattern in snake_case (e.g., `borme_lookup`, `entity_lookup`, `get_competitors`). Verbs like lookup, get, search, verify are appropriate and descriptive of the action.

Tool Count5/5

With 6 tools, the server is well-scoped for entity verification. Each tool adds value without redundancy. The count is within the ideal range (3-15) and matches the domain's complexity.

Completeness4/5

Covers core verification workflows: entity lookup, VAT verification, competitor discovery, and registry search. Minor gaps include no direct tool for detailed corporate history or financial data, but these are reasonable omissions for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

nordic-data
cloud.nordicdata
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Government Data Open Data
2
eu-verify A
io.github.contentfactory
European business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
Legal & Compliance Security Finance
1921
nordic-data A
io.github.Mnymann
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
Legal & Compliance Finance
1121
Sirenic A
eu.sirenic
French & European company registry for AI agents: KYB, sanctions, annual accounts. x402, no API key.
Government Data Open Data
1082

Related MCP Servers

eu-company-mcp-server
Government Data Finance Search
AiAgentKarl
A
license
A
quality
D
maintenance
MCP server for EU company and business data. 9 tools: company search (GLEIF, 2M+ entities), LEI lookup, corporate structures (parent/subsidiaries), trade register search, EU VAT validation (VIES), GDP, unemployment, inflation, and business demography (Eurostat). All APIs free, no keys required.
Updated 6 months ago (2026-04-03 16:15 UTC)
9
5
MIT
Bizfile MCP
Government Data Search Finance
OjasKord
A
license
Not graded
quality
A
maintenance
Provides real-time company verification and corporate intelligence by accessing global registries like UK Companies House, Singapore ACRA, and OpenCorporates. It enables AI agents to perform KYC tasks, retrieve company profiles, and conduct automated risk assessments for due diligence workflows.
Updated 14 days ago (2026-09-08 00:00 UTC)
101 npm
MIT
CompanyScope
Research & Data Open Data
Stewyboy1990
A
license
A
quality
F
maintenance
Delivers comprehensive company intelligence in a single tool call, aggregating profiles, tech stacks, key people, news, and corporate data from any domain or company name. Sources data from Wikipedia, GitHub, OpenCorporates, and web scraping to provide structured business insights using only free public APIs.
Updated 5 months ago (2026-04-12 09:37 UTC)
6
29 npm
4
MIT
mcp-europe-business
Legal & Compliance Finance
josemvelez78
F
license
A
quality
D
maintenance
European business compliance suite for AI agents — 28 tools covering tax ID validation (PT, ES, FR, DE, IT, UK, NL), IBAN verification, EU VAT rates, invoice requirements, e-invoicing rules, payment terms, labor calendar helpers, VAT breakdown calculations and invoice schema validation for 18+ European countries.
Updated 4 months ago (2026-05-09 18:28 UTC)
28
-

Appeared in Searches

EU-Verify Identity or Document Verification Service

ENTIA MCP Server

Schnellstart (< 2 Minuten)

Option 1: Remote-MCP-Server (empfohlen)

Option 2: REST-API

Option 3: Python-Client (in diesem Repository)

12 MCP-Tools

Preise

Datenquellen

Links

Über

Lizenz

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches