What can you do with this server?

ENTIA provides structured business intelligence and entity verification for AI agents, covering 5.5M+ verified entities across 34 countries with particularly deep coverage of Spain. It offers 20 MCP tools across these areas: Entity Lookup & Search * Look up verified business entities by CIF, EU VAT, LEI, or company name, with cross-references to BORME, VIES, GLEIF, and Wikidata, including a trust score (0–100) * Search 5.5M entities by name, sector, city, and country * Retrieve full JSON-LD (Schema.org) structured entity profiles Spanish BORME (Mercantile Registry) * Search 40.3M mercantile acts (2009–2026) by company name or CIF * Track newly formed companies filtered by CNAE sector and/or province * Monitor officer appointments/removals for KYC/KYB due diligence EU VAT Verification * Validate EU VAT numbers in real time via VIES across all 27 EU member states Healthcare Professional Verification (Spain) * Verify professionals against REPS (523K+ professionals from Spain's Ministry of Health) * Verify dentists via the Consejo General de Dentistas registry (44K+ colegiados) * Verify psychologists via the COP registry * Search professionals by specialty (nurses, physicians, dentists, pharmacists, veterinarians, etc.) Healthcare Center Search (Spain) * Search REGCESS — Spain's national registry of 120K+ centers (hospitals, clinics, pharmacies, etc.) * Search regional centers across Madrid, Cataluña, Valencia, Euskadi, Navarra, and Cantabria * Search pharmacies and dental clinics (including Cataluña-specific dental clinic data) Socioeconomic & Market Intelligence (Spain) * Get postal code profiles (income, unemployment, population, business density, ICE/lead scores) for 11,241 Spanish postal codes * Get demographic and business profiles for 8,131 Spanish municipalities * Find competitors in a given sector and city Platform Metadata * Retrieve real-time platform statistics on registry size, country, and sector coverage

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.

de en es ja ko ru zh

ENTIA Entity Verification

Official

by ENTIA-IA

Overview Schema Related Servers Score Discussions

Python

Remote

ENTIA MCP Server

Structured business intelligence for AI agents.

ENTIA provides verified entity data across 10 countries — accessible via Model Context Protocol (MCP) or REST API.

Metric	Value
Verified entities	11,330,392
Countries	10
BORME mercantile acts	40.3M
Healthcare professionals	570K+
MCP tools	12
REST endpoints	4

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: Bizfile MCP

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 across 10 countries by name, keyword, country, 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, countries, sources.
`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).

Pricing

Free tier: 100 requests/month. Authoritative pricing is published live at entia.systems/.well-known/ai-pricing.json.

Tier	Price	Requests	Overage
TRACE	Free	100/month	Hard block
SIGNAL	EUR 29/month	500/month	Hard block
BUILD	EUR 99/month	2,500/month	Hard block
INTEGRATE	EUR 399/month	10,000/month	EUR 0.15/req
OPERATE	EUR 1,499/month	100,000/month	EUR 0.10/req
SCALE	EUR 2,500+/month	500,000/month	EUR 0.05/req (contact)
ENTERPRISE	Custom	Unlimited	—

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)

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
772

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 5 months ago (2026-04-03 16:15 UTC)
9
4
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 13 days ago (2026-08-24 07:47 UTC)
249
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
104
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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ENTIA-IA/entia-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

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

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

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API