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

AI 에이전트를 위한 구조화된 비즈니스 인텔리전스.

ENTIA는 10개국의 검증된 엔티티 데이터를 제공하며, Model Context Protocol (MCP) 또는 REST API를 통해 접근할 수 있습니다.

지표	값
검증된 엔티티	11,330,392
국가	10
BORME 상업 등기 기록	40.3M
의료 전문가	570K+
MCP 도구	12
REST 엔드포인트	4

빠른 시작 (2분 미만)

옵션 1: 원격 MCP 서버 (권장)

설치가 필요 없습니다. MCP 클라이언트를 직접 연결하세요:

Claude Desktop — claude_desktop_config.json에 추가:

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

Cursor IDE — .cursor/mcp.json에 추가:

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

그런 다음 시도해 보세요:

Look up Telefonica in Spain

옵션 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"

옵션 3: Python 클라이언트 (이 저장소 내)

Python 클라이언트는 이 저장소의 entia_mcp/ 디렉토리에 있으며, 일부 도구를 편의 메서드로 래핑합니다. 전체 12개 도구는 호스팅 엔드포인트(옵션 1)를 통해 항상 사용할 수 있습니다. PyPI 패키지 배포가 예정되어 있습니다.

Related MCP server: Bizfile MCP

12개 MCP 도구

도구	기능
`entity_lookup`	이름, CIF/NIF, EU VAT 또는 LEI로 모든 기업의 신원을 확인합니다. BORME, VIES, GLEIF를 교차 검증합니다.
`search_entities`	이름, 키워드, 국가 또는 업종별로 10개국의 검증된 엔티티를 검색합니다.
`verify_vat`	VIES를 통한 실시간 EU VAT 검증 (27개 회원국).
`zone_profile`	우편번호별 스페인 사회경제 프로필 (INE/SEPE/AEAT): 소득, 고용, 사업 밀도.
`get_competitors`	동일 업종 및 지역의 실제 경쟁사.
`get_showcase`	선별된 IBEX35 + EU 쇼케이스 엔티티. 무료이며 할당량을 소모하지 않습니다.
`professional_lookup`	24개 스페인 의료/법률/심리 분야의 전문가 등록을 확인합니다. DPA(GDPR 제28조)가 필요합니다.
`get_full_dossier`	집계기: 한 번의 호출로 엔티티에 대한 90개 이상의 필드 (4개 ENTIA 소스 결합).
`get_platform_stats`	실시간 플랫폼 통계: 엔티티, 국가, 소스.
`run_risk_audit`	모든 도메인에 대한 AI 준비도 + 디지털 위험 감사.
`get_entia_home`	엔티티에 대한 전체 Schema.org JSON-LD @graph (Entia Home).
`get_entity_home_projection`	Entia Home 레코드의 기계 판독 가능 프로젝션 (v1).

가격

무료 티어: 월 100회 요청. 공식 가격은 entia.systems/.well-known/ai-pricing.json에서 실시간으로 확인할 수 있습니다.

티어	가격	요청 수	초과 요금
TRACE	무료	월 100회	하드 차단
SIGNAL	월 EUR 29	월 500회	하드 차단
BUILD	월 EUR 99	월 2,500회	하드 차단
INTEGRATE	월 EUR 399	월 10,000회	요청당 EUR 0.15
OPERATE	월 EUR 1,499	월 100,000회	요청당 EUR 0.10
SCALE	월 EUR 2,500+	월 500,000회	요청당 EUR 0.05 (문의)
ENTERPRISE	맞춤형	무제한	—

API 키 받기: entia.systems/mcp-setup

데이터 소스

모든 데이터는 공식 공공 등록부에서 제공됩니다:

BORME -- 스페인 상업 등기부 (BOE)
VIES -- EU VAT 검증 (유럽 위원회)
GLEIF -- 법인 식별자 (Global LEI Foundation)
Wikidata -- 지식 그래프 (Wikimedia Foundation)
REPS -- 스페인 의료 전문가 등록부
INE -- 스페인 국립 통계청
SEPE -- 스페인 고용 서비스
AEAT -- 스페인 국세청
Companies House -- 영국 기업 등록부
Sirene/INSEE -- 프랑스 기업 등록부

링크

소개

PrecisionAI Marketing OU (에스토니아, EU)가 제작했습니다.

VAT: EE102780516
DUNS: 565868914
e-Residency 인증
eIDAS 준수

라이선스

코드: MIT (LICENSE 참조). 이 서버는 경량 MCP 래퍼로, JSON-RPC를 사용하며 ENTIA API로 프록시합니다. 래퍼를 공개로 유지하는 것은 의도적입니다 — 모든 클라이언트가 전송되고 반환되는 내용을 정확히 감사할 수 있기 때문입니다.

데이터: 독점 — MIT는 데이터에 적용되지 않습니다. 이 서버를 통해 접근하는 검증된 엔티티 코퍼스는 별도로 라이선스되며 API 키로 접근이 제어됩니다. 데이터 사용은 데이터 라이선스 프레임워크, MCP 약관 및 서비스 약관의 적용을 받으며, sui generis 데이터베이스 권리(지침 96/9/EC)로 보호됩니다. 이 저장소를 클론한다고 해서 코퍼스에 대한 어떠한 권리도 부여되지 않습니다.

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