Skip to main content
Glama

ENTIA Entity Verification

by io.github.entia-systems-core

Search Entities

search_entities
Read-onlyIdempotent

Search verified entities across 10 countries by name, keyword, country, city or sector. Answers 'find me a dentist in Madrid' / 'list law firms in Barcelona'. sector is a closed vocabulary — see the enum; aliases such as abogados resolve to their canonical slug. Anonymous callers receive a trace-level preview (name + city); authenticated TRACE+ keys unlock full records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSearch query — company name or keywords
cityNoCity name (Madrid, Barcelona, Valencia, Sevilla, London)
limitNoMax results (default 10, max 50)
sectorNoSector filter. Canonical: dental, legal, estetica, psicologia, medicos, talleres, veterinarios, reformas, inmobiliarias, asesorias, gimnasios… Aliases (abogados, salud, dentist, beautysalon…) resolve to a canonical slug and the response declares the translation in _meta.sector_resolved_from.
countryNoISO country code (es, gb, fr)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
_metaNoCarries sector_resolved_from when an alias was translated
countNo
filtersNoFilters actually applied — echoes q/sector/city/country
entitiesNoEach carries name, city, sector and canonical Entia Home URL

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Paged catalogue search over the verified corpus.",
+  "properties": {
+    "_meta": {
+      "description": "Carries sector_resolved_from when an alias was translated",
+      "type": "object"
+    },
+    "count": {
+      "type": "integer"
+    },
+    "entities": {
+      "description": "Each carries name, city, sector and canonical Entia Home URL",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "filters": {
+      "description": "Filters actually applied — echoes q/sector/city/country",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / city
      Added value: +{
+  "description": "City name (Madrid, Barcelona, Valencia, Sevilla, London)",
+  "maxLength": 100,
+  "minLength": 2,
+  "type": "string"
+}
    • changedInput schema / properties / sector / description
      Previous value: -"Sector filter (dental, legal, talleres, estetica, …)"New value: +"Sector filter. Canonical: dental, legal, estetica, psicologia, medicos, talleres, veterinarios, reformas, inmobiliarias, asesorias, gimnasios… Aliases (abogados, salud, dentist, beautysalon…) resolve to a canonical slug and the response declares the translation in _meta.sector_resolved_from."
    • addedInput schema / properties / sector / enum
      Added value: +[
+  "abogados",
+  "accountingservice",
+  "asesoria",
+  "asesorias",
+  "attorney",
+  "automocion",
+  "automotivebusiness",
+  "autorepair",
+  "barberia",
+  "barberias",
+  "beautysalon",
+  "belleza",
+  "clinicas",
+  "construccion",
+  "consultoria",
+  "dental",
+  "dentist",
+  "dentista",
+  "ecommerce",
+  "educacion",
+  "energia",
+  "estetica",
+  "exercisegym",
+  "farmacia",
+  "farmacias",
+  "financial",
+  "financialservice",
+  "fisio",
+  "fisioterapia",
+  "foodestablishment",
+  "generalcontractor",
+  "gestion",
+  "gestoria",
+  "gestorias",
+  "gimnasio",
+  "gimnasios",
+  "hairsalon",
+  "healthandbeautybusiness",
+  "healthcare",
+  "healthclub",
+  "homeandconstructionbusiness",
+  "hospital",
+  "hospitality",
+  "inmobiliaria",
+  "inmobiliarias",
+  "insurance",
+  "insuranceagency",
+  "legal",
+  "legalservice",
+  "medicalbusiness",
+  "medicalclinic",
+  "medico",
+  "medicos",
+  "nutricion",
+  "optica",
+  "opticas",
+  "optician",
+  "peluqueria",
+  "peluquerias",
+  "pharmacy",
+  "physician",
+  "physiotherapyclinic",
+  "podologia",
+  "psicologia",
+  "psychologist",
+  "realestate",
+  "realestateagent",
+  "reformas",
+  "restauracion",
+  "restaurant",
+  "restaurantes",
+  "rrhh",
+  "saas",
+  "salud",
+  "security",
+  "seguros",
+  "sportsactivitylocation",
+  "taller",
+  "talleres",
+  "telecom",
+  "turismo",
+  "veterinario",
+  "veterinarios",
+  "veterinarycare"
+]
  3. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / country / description
      Previous value: -"ISO country code filter (e.g. \"es\", \"gb\", \"fr\")"New value: +"ISO country code (es, gb, fr)"
    • changedInput schema / properties / sector / description
      Previous value: -"Sector filter. Examples: dental, legal, talleres, estetica, inmobiliarias, hosteleria, reformas, veterinarios, asesorias, gimnasios, psicologia, and 24+ more"New value: +"Sector filter (dental, legal, talleres, estetica, …)"
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating, and idempotent nature is covered. The description adds valuable context beyond annotations: the 'sector' parameter has alias resolution (e.g., 'abogados' resolves to canonical slug) with the response declaring the translation in _meta.sector_resolved_from. It also explains the access level difference between anonymous and authenticated callers. These are important behavioral traits not captured by the annotations.

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 two sentences of core purpose plus one sentence each for sector details and authentication behavior. It is well front-loaded with the main purpose and examples. The only minor issue is that the sector detail could be slightly more compact, but overall every sentence justifies its presence and it remains concise at around 70 words.

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 complexity (5 parameters, 1 with a large enum), 100% schema coverage, and existence of an output schema, the description covers all necessary aspects: what the tool searches, what parameters are available with important behavioral notes (sector alias resolution, auth-based access levels), and examples. The output schema presumably documents the return format, so the description does not need to. All dimensions are sufficiently addressed.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all five parameters with types, constraints, and descriptions. The description adds value by explaining that 'sector' is a closed vocabulary with alias resolution behavior and that aliases like 'abogados' resolve to canonical slugs with response metadata. It also clarifies the 'city' parameter with example city names beyond what the schema provides. This is a clear addition of 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 the tool searches verified entities across 10 countries by various criteria (name, keyword, country, city, sector). It gives concrete query examples like 'find me a dentist in Madrid' and 'list law firms in Barcelona', which explicitly differentiate it from sibling tools that do entity lookups by ID (entity_lookup, professional_lookup) or retrieve dossier/competitor data (get_full_dossier, get_competitors). The verb is specific and the resource is well-defined.

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 provides clear usage context by mentioning search queries and filters, and gives example natural language queries. It also notes that anonymous callers get limited results while authenticated TRACE+ keys unlock full records. However, it does not explicitly state when NOT to use this tool in favor of siblings like entity_lookup or professional_lookup, which would be useful for disambiguation.

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

All ENTIA Entity Verification toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

Most tools target distinct resources, but get_entia_home and get_entity_home_projection are near-duplicates representing the same Entia Home concept from slightly different technical angles. entity_lookup and get_full_dossier also overlap since entity_lookup already mentions returning the full paid dossier, and get_competitors is a specialized variant of search_entities.

Naming Consistency3/5

The set mixes get_* names with bare action names like entity_lookup, search_entities, verify_vat, and professional_lookup, so there is no single consistent verb_noun pattern. The names are still readable and somewhat predictable, but the inconsistency is noticeable and get_entia_home vs get_entity_home_projection adds confusion.

Tool Count4/5

Twelve tools is within a reasonable range for an entity-verification server, and most tools serve a distinct due-diligence purpose. However, a few tools are auxiliary or redundant: get_showcase and get_platform_stats are exploratory rather than core verification, and the two Entia Home retrieval tools could be consolidated.

Completeness4/5

The server covers the core verification lifecycle well: entity lookup by identifiers, flexible search, VAT validation, professional verification, competitor discovery, full dossiers, and risk auditing. Minor gaps exist, such as no direct way to fetch a raw single source like VIES or BORME independently and no entity relationship/ownership endpoint, but these are workable for typical KYB workflows.

Resources