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

Inteligencia empresarial estructurada para agentes de IA.

ENTIA proporciona datos de entidades verificadas en 10 países, accesibles a través de Model Context Protocol (MCP) o API REST.

Métrica	Valor
Entidades verificadas	11,330,392
Países	10
Actos mercantiles BORME	40.3M
Profesionales sanitarios	570K+
Herramientas MCP	12
Endpoints REST	4

Inicio rápido (< 2 minutos)

Opción 1: Servidor MCP remoto (recomendado)

No se necesita instalación. Conecta tu cliente MCP directamente:

Claude Desktop — añade a claude_desktop_config.json:

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

Cursor IDE — añade a .cursor/mcp.json:

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

Luego prueba:

Look up Telefonica in Spain

Opción 2: API REST

# 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"

Opción 3: Cliente Python (en este repositorio)

Un cliente Python se encuentra en este repositorio bajo entia_mcp/ (envuelve un subconjunto de herramientas como métodos de conveniencia). La superficie completa de 12 herramientas está siempre disponible a través del endpoint alojado (Opción 1). Se planea publicar un paquete PyPI.

Related MCP server: Bizfile MCP

12 herramientas MCP

Tool	Qué hace
`entity_lookup`	Verifica la identidad de cualquier empresa por nombre, CIF/NIF, IVA UE o LEI. Contrasta con BORME, VIES, GLEIF.
`search_entities`	Busca entidades verificadas en 10 países por nombre, palabra clave, país o sector.
`verify_vat`	Validación de IVA UE en tiempo real a través de VIES (27 estados miembros).
`zone_profile`	Perfil socioeconómico español por código postal (INE/SEPE/AEAT): ingresos, empleo, densidad empresarial.
`get_competitors`	Competidores reales en el mismo sector y geografía.
`get_showcase`	Entidades destacadas seleccionadas de IBEX35 + UE. Gratuito, no consume cuota.
`professional_lookup`	Verifica registros profesionales en 24 verticales españolas de salud/legal/psicología. Requiere DPA (RGPD Art. 28).
`get_full_dossier`	Agregador: más de 90 campos sobre una entidad en una sola llamada (combina 4 fuentes de ENTIA).
`get_platform_stats`	Estadísticas de plataforma en vivo: entidades, países, fuentes.
`run_risk_audit`	Auditoría de preparación para IA + riesgo digital para cualquier dominio.
`get_entia_home`	Grafo JSON-LD completo de Schema.org para una entidad (Entia Home).
`get_entity_home_projection`	Proyección legible por máquina de un registro Entia Home (v1).

Precios

Nivel gratuito: 100 solicitudes/mes. Los precios autoritativos se publican en vivo en entia.systems/.well-known/ai-pricing.json.

Nivel	Precio	Solicitudes	Exceso
TRACE	Gratis	100/mes	Bloqueo duro
SIGNAL	EUR 29/mes	500/mes	Bloqueo duro
BUILD	EUR 99/mes	2,500/mes	Bloqueo duro
INTEGRATE	EUR 399/mes	10,000/mes	EUR 0.15/solicitud
OPERATE	EUR 1,499/mes	100,000/mes	EUR 0.10/solicitud
SCALE	EUR 2,500+/mes	500,000/mes	EUR 0.05/solicitud (contacto)
ENTERPRISE	Personalizado	Ilimitado	—

Obtén tu clave API: entia.systems/mcp-setup

Fuentes de datos

Todos los datos provienen de registros públicos oficiales:

BORME -- Registro Mercantil Español (BOE)
VIES -- Validación de IVA UE (Comisión Europea)
GLEIF -- Identificadores de Entidades Legales (Fundación Global LEI)
Wikidata -- Grafo de Conocimiento (Fundación Wikimedia)
REPS -- Registro Español de Profesionales Sanitarios
INE -- Instituto Nacional de Estadística de España
SEPE -- Servicio Público de Empleo Estatal
AEAT -- Agencia Estatal de Administración Tributaria
Companies House -- Registro de empresas del Reino Unido
Sirene/INSEE -- Registro de empresas francés

Enlaces

Acerca de

Construido por PrecisionAI Marketing OU (Estonia, UE).

IVA: EE102780516
DUNS: 565868914
Certificado de e-Residencia
Cumple con eIDAS

Licencia

Código: MIT (ver LICENSE). Este servidor es un envoltorio MCP ligero: habla JSON-RPC y actúa como proxy hacia la API de ENTIA. Mantener el envoltorio abierto es deliberado: permite que cualquier cliente audite exactamente lo que se envía y se recibe.

Datos: propietarios — MIT no se aplica a ellos. El corpus de entidades verificadas al que se accede a través de este servidor está licenciado por separado y el acceso está controlado por clave API. El uso de los datos se rige por el Marco de licencia de datos, los Términos de MCP y los Términos de servicio, y está protegido por el derecho sui generis sobre bases de datos (Directiva 96/9/CE). Clonar este repositorio no otorga ningún derecho sobre el corpus.

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