What can you do with this server?

Summary: Verify and research business entities, Spanish corporate records, EU VAT status, local socioeconomic profiles, and competitors. * entity_lookup — verify a business by name, CIF, EU VAT, or LEI; returns trust score, BORME acts count, LEI, Wikidata QID, and jurisdiction. * search_entities — search verified entities by name/keyword, country, sector, or city; returns contact, website, address, and sector. * borme_lookup — retrieve Spanish BORME mercantile acts, officers, founding date, and corporate events. * verify_vat — validate EU VAT numbers live via VIES across 27 member states. * zone_profile — get Spanish postal-code socioeconomic data: income, unemployment, population, property price, and broadband coverage. * get_competitors — find verified competitors in the same sector and city. Note: The README describes 12 MCP tools, but the provided server schema exposes these 6 tools.

Which integrations are available for this server?

Provides LangChain integration tools for building AI agents with business intelligence capabilities, including entity search, profile lookup, and healthcare professional verification. Offers Python client library for programmatic access to business intelligence data, including entity search, profile retrieval, VAT verification, and platform statistics. Integrates Wikidata knowledge graph data to enhance entity profiles with verified information, contributing to comprehensive business intelligence dossiers. Utilizes Wikimedia Foundation's Wikidata as a data source for entity verification and enrichment within business intelligence profiles.

How do I use ENTIA Entity Verification?

This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions: * ENTIA Entity Verification

de en es ja ko ru zh

ENTIA Entity Verification

Official

by ENTIA-IA

Overview Schema Source Related Servers Discussions Admin

Python

Remote

ENTIA MCP Server

Structured business intelligence for AI agents.

ENTIA gives AI agents verified business identity data from official public registries — accessible via Model Context Protocol (MCP) or REST API.

Metric	Value
Verified entities	11,330,391
BORME mercantile acts	40.3M
Active sources	16
MCP tools	12

Reference snapshot / tools verified on 2026-10-14; do not assume the snapshot is updated on every registry recrawl. Query get_platform_stats for current coverage and tools/list for current tool names. An entity registry identifier is not a VIES-confirmed VAT number.

Quick Start (< 2 minutes)

Option 1: Remote MCP Server (recommended)

No installation needed. Connect your MCP client directly:

Claude Desktop — add to claude_desktop_config.json:

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

Cursor IDE — add to .cursor/mcp.json:

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

Then try:

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 this repo)

A Python client lives in this repo under entia_mcp/ (wraps a subset of tools as convenience methods). The full 12-tool surface is always available via the hosted endpoint (Option 1). A published PyPI package is planned.

Related MCP server: CompanyScope

12 MCP Tools

Tool	What it does
`entity_lookup`	Verify identity of any business by name, CIF/NIF, EU VAT or LEI. Cross-checks BORME, VIES, GLEIF.
`search_entities`	Search verified entities by name, keyword, country, city or sector.
`verify_vat`	Real-time EU VAT validation via VIES (27 member states).
`zone_profile`	Spanish socioeconomic profile by postal code (INE/SEPE/AEAT): income, employment, business density.
`get_competitors`	Real competitors in the same sector and geography.
`get_showcase`	Curated IBEX35 + EU showcase entities. Free, does not consume quota.
`professional_lookup`	Verify professional registrations across 24 Spanish health/legal/psychology verticals. Requires DPA (GDPR Art. 28).
`get_full_dossier`	Aggregator: 90+ fields about an entity in one call (combines 4 ENTIA sources).
`get_platform_stats`	Live platform stats: entities, sources. Free, does not consume quota.
`run_risk_audit`	AI-readiness + digital risk audit for any domain.
`get_entia_home`	Full Schema.org JSON-LD @graph for an entity (Entia Home).
`get_entity_home_projection`	Machine-readable projection of an Entia Home record (v1).

Try it free (no key)

entity_lookup works without an API key and returns a trace-level identity preview. get_showcase and get_platform_stats do not consume quota.

Pricing

Monthly subscription in EUR. No overage on any plan: when you reach your monthly quota, requests are paused (HTTP 429) until the next billing month. Billing unit: entity returned ("entidad consultada"), deduplicated per UTC calendar day.

Plan	EUR / month	Entities / month
TRACE	Free	100 (preview)
EDGE	9.90	10,000 (edge-cached responses only)
SIGNAL	29	500
BUILD	99	2,500
INTEGRATE	399	10,000
OPERATE	1,499	100,000
SCALE	Custom, from 2,500	500,000+
ENTERPRISE	Custom	—

Human pricing: entia.systems/pricing · Machine-readable: ai-pricing.json · /api/v1/mcp/plans

Maintainers of external MCP directories: this GitHub README and glama.json supersede older cards describing 5.5M entities / 34 countries / 20 MCP tools / per-call overage. Please refresh the existing listing and use the canonical io.github.entia-systems-core/entity-verification registry identity, rather than creating a duplicate. Publisher-side metadata is not proof that a third-party index has refreshed.

API/MCP access is not a data licence. Plans cover per-lookup grounding only. AI training, fine-tuning, dataset creation and bulk extraction require the separate ENTIA AI Training & Corpus License (ENTIA-LTC-1.0).

Get your API key: entia.systems/mcp-setup

Data Sources

All data comes from official public registries:

BORME -- Spanish Mercantile Registry (BOE)
VIES -- EU VAT validation (European Commission)
GLEIF -- Legal Entity Identifiers (Global LEI Foundation)
Wikidata -- Knowledge Graph (Wikimedia Foundation)
REPS -- Spanish Healthcare Professionals Registry
INE -- Spanish National Statistics Institute
SEPE -- Spanish Employment Service
AEAT -- Spanish Tax Authority
Companies House -- UK company registry
Sirene/INSEE -- French company registry

About

Built by PrecisionAI Marketing OU (Estonia, EU).

VAT: EE102780516
DUNS: 565868914
e-Residency certified
eIDAS compliant

License

Code: MIT (see LICENSE). This server is a thin MCP wrapper: it speaks JSON-RPC and proxies to the ENTIA API. Keeping the wrapper open is deliberate — it lets any client audit exactly what is sent and returned.

Data: proprietary — MIT does not apply to it. The verified-entity corpus reached through this server is licensed separately and access is controlled by API key. Use of the data is governed by the Data Licensing Framework, the MCP Terms and the Terms of Service, and is protected by the sui generis database right (Directive 96/9/EC). Cloning this repository grants no right whatsoever over the 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)

Name	Required	Description	Default
`query`	Yes

Output 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)

Name	Required	Description	Default
`query`	Yes

Output 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

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

Output 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

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

Output 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)

Name	Required	Description	Default
`vat_id`	Yes

Output 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...)

Name	Required	Description	Default
`postal_code`	Yes

Output 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

ResponsivenessLimited data

Resources

Related MCP Connectors

AhelA
ai.ahel
Data and tools for your AI agent: company, people, SEO, social and EU register data. Pay per call.
Research & Data Social Media Government Data
111
https://mcp.ahel.ai
nordic-data
cloud.nordicdata
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Government Data Open Data
2
https://api.nordicdata.cloud/mcp
eu-verifyA
io.github.contentfactory
European business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
Legal & Compliance Security Finance
1921
https://data.greeneris.io/mcp
nordic-dataA
io.github.Mnymann
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
Legal & Compliance Finance
1121
https://nordic-data-mcp-production.up.railway.app/mcp/auth

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 7 months ago (2026-04-03 16:15 UTC)
9
6
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 7 months ago (2026-04-12 09:37 UTC)
6
87 npm
4
MIT
mcp-europe-business
Legal & Compliance Finance
josemvelez78
A
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 6 months ago (2026-05-09 18:28 UTC)
28
MIT
eu-verify
Government Data Legal & Compliance Open Data
contentfactory
A
license
Not graded
quality
F
maintenance
eu-verify lets AI agents verify any European business partner: company existence (official French SIREN registry), insolvency records (BODACC), EU VAT validation before invoicing (VIES), SIRET/IBAN/LEI checks, address and email verification, French business-day deadlines and EU public tenders. 10 paid MCP tools + a free catalog tool, plus 81 HTTP endpoints. Each call costs $0.001-$0.01 in USDC on
Updated 3 months ago (2026-07-25 05:31 UTC)
1
MIT

Appeared in Searches

EU-Verify Identity or Document Verification Service

ENTIA MCP Server

Quick Start (< 2 minutes)

Option 1: Remote MCP Server (recommended)

Option 2: REST API

Option 3: Python client (in this repo)

12 MCP Tools

Try it free (no key)

Pricing

Data Sources

Links

About

License

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