ENTIA Entity Verification MCP
Server Details
Spain's deepest business intelligence for AI agents. Verify companies via BORME, VIES, GLEIF and Wikidata. Access 52M+ records across 34 countries: entity lookup, VAT validation, BORME filings, zone economic profiles, and competitor search.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 13 of 13 tools scored. Lowest: 3.1/5.
Tools are mostly distinct in purpose, with clear descriptions. Some overlap exists (e.g., entity_lookup vs. search_entities, ai_ready_profile vs. get_entia_home), but descriptions help differentiate. Overall, an agent can reliably select the right tool.
Names use snake_case and common verbs (get_, lookup_, search_), but inconsistency arises with noun-phrase names like ai_ready_profile and zone_profile, and mixing of 'get', 'lookup', 'search', and 'verify' without a strict pattern. Still readable and predictable enough.
With 13 tools, the set is well-scoped for entity verification and business intelligence. Each tool serves a specific purpose without redundancy, and the count feels appropriate for the domain's complexity.
The tool surface covers core verification needs: identity lookup, search, VAT, professional registrations, competitors, and risk audits. Minor gaps exist (e.g., no address verification, limited global coverage), but the set is solid for its EU/Spanish focus.
Available Tools
13 toolsai_ready_profileAInspect
Full AI-ready JSON-LD profile for any entity — 4-node @graph (Organization, Place, LocalBusiness, PostalAddress). Designed for direct AI citation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or domain |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the output structure but does not disclose behavioral aspects like whether data is fetched live, cached, or any side effects. It vaguely mentions 'designed for direct AI citation' but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no extraneous information. It front-loads the key purpose and output structure, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description sufficiently covers the output format. It mentions the JSON-LD structure and the 4-node graph, which is a good substitute for an output schema. However, it could improve by clarifying the response format or whether it's a direct profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description in the schema is clear. The tool description does not add additional meaning beyond what the schema provides, so it achieves the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: producing an AI-ready JSON-LD profile with a specific 4-node structure. It uses specific verbs and resources, and distinguishes itself from sibling tools by emphasizing the structured output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining AI-ready profiles, but it does not explicitly state when to use this tool versus siblings or any condition for not using it. There is no guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
entity_lookupAInspect
Look up any business entity by name, CIF/NIF, EU VAT, or LEI. Free callers receive a trace-level identity preview; authenticated callers receive the full paid dossier.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Company name, CIF/NIF (B82846825), EU VAT (ESB82846825), or LEI (20 chars) | |
| name | No | Alias for `q` — accepted for compatibility with clients that send `name`. | |
| query | No | Alias for `q` — accepted for compatibility with clients that send `query`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It reveals that responses differ by authentication status but lacks details on error handling, empty results, rate limits, or data freshness. The behavioral insight provided is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and behavioral distinction. No unnecessary words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the main use case and the key behavioral difference based on authentication. However, it could mention what happens with invalid identifiers or no results to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context about authentication affecting results, but does not elaborate on parameter formats beyond what the schema already contains. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up business entities by name or identifier, specifies supported identifier types (CIF/NIF, EU VAT, LEI), and distinguishes it from siblings like search_entities which likely does broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that free vs authenticated callers get different levels of detail, providing some usage context. However, it does not explicitly guide when to use this tool over alternatives like search_entities or get_full_dossier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_competitorsAInspect
Find real competitors in the same sector and geography. Ranked entities with identity + location + sector matching.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (Madrid, Barcelona, London, Paris) | |
| limit | No | ||
| sector | Yes | ENTIA sector slug (estetica, dental, psicologia, legal, …) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions ranking but does not disclose behavioral traits such as authentication needs, rate limits, or what happens if no competitors are found. More context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should cover return format. It mentions 'ranked entities' but lacks details on pagination, fields returned, or empty result behavior. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (city and sector described, limit not). The description repeats matching on sector and geography but adds no new meaning beyond the schema. The limit parameter lacks explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds 'real competitors' in a specific sector and geography, using identity, location, and sector matching. This distinguishes it from sibling tools like entity_lookup or search_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for identifying competitors via ranking, but lacks explicit guidance on when to use it versus alternatives like general entity search. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entia_homeBInspect
Retrieve full Schema.org JSON-LD @graph (4 nodes: WebPage, Entity, Verification Report, Territorial Profile) for an entity's Entia Home page.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug (madrid, barcelona, london) | |
| slug | Yes | Business slug (clinica-dental-sonrisa) | |
| sector | Yes | Industry slug (dental, legal, talleres, …) | |
| country | Yes | ISO 3166-1 alpha-2 (es, gb, fr) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It states 'Retrieve' implying read-only operation, but does not disclose any behavioral traits such as rate limits, authentication needs, or what happens if the entity is not found. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key information: the action, the resource, and the structure. Every word is necessary and no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description names the four nodes in the returned graph, providing good context. It lacks details on error handling or pagination, but for a retrieval tool with four parameters, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented. The overall description does not add additional meaning beyond the schema; it only ties parameters together conceptually. Baseline 3 is appropriate as the schema sufficiently describes the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Retrieve) and the resource (full Schema.org JSON-LD @graph with four named nodes for an entity's Entia Home page). It distinguishes itself by referencing the specific structure, but does not explicitly differentiate from sibling tools like entity_lookup or get_showcase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as entity_lookup or get_showcase. The description does not mention when not to use it or any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_full_dossierAInspect
Aggregator — 90+ fields about an entity in one call. Combines 4 ENTIA sources in parallel: identity, zone, BORME, VIES. Killer tool for due diligence/KYB.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name, CIF/NIF, EU VAT, or LEI |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool combines sources in parallel and returns 90+ fields, which is informative. It does not mention auth needs or rate limits, but as a read-only aggregator this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The key information is front-loaded: 'Aggregator — 90+ fields'. Every sentence is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as an aggregator of 4 sources, the description explains the sources and field count. No output schema exists, but the description hints at the output richness. It could mention the output structure but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'query' parameter. The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'Aggregator' that combines 4 ENTIA sources and returns 90+ fields. The verb 'Aggregator' and resource 'entity' are specific, and it distinguishes from siblings by being a comprehensive one-call tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Killer tool for due diligence/KYB', providing clear usage context. However, it does not mention when not to use it or suggest alternatives, though sibling tools imply individual lookups for simpler needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_platform_statsAInspect
Live platform stats: entities count, countries, sources, homes published.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It states 'Live' indicating near real-time, and lists the data. It does not mention side effects, authorization, or rate limits, but given it is a read-only stats tool with no parameters, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key purpose 'Live platform stats', and lists the data. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides enough detail about the returned data (entities count, countries, sources, homes published). It could mention the format or any limitations, but it is adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the schema provides no information. The description adds meaning by specifying what the stats include, which is essential for the agent to understand the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'live platform stats' and lists specific data points: entities count, countries, sources, homes published. This distinguishes it from sibling tools that focus on individual entities or profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregate platform data, but does not explicitly state when to use vs alternatives or provide exclusions. The sibling tools are all specific lookups, so the context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_showcaseAInspect
Curated IBEX35 + EU entity examples. FREE — does not consume quota. Use to explore data depth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses it's free and quota-free, implying no destructive action, but lacks details on output or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no waste. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given zero parameters and no output schema; states purpose and content, but could mention return format for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, but description adds meaning by specifying the content (IBEX35+EU examples) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Curated IBEX35 + EU entity examples' and invites exploration, but it does not explicitly state the verb (e.g., returns a list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates it's free and for exploration, but does not specify when to use over siblings like search_entities or entity_lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_by_domainBInspect
Look up a business entity by its website domain. STATUS: Coming in v1.2 — endpoint not yet deployed.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name (example.com or www.example.com) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description only discloses that the endpoint is not deployed. It fails to detail expected behavior, side effects, or error handling if the tool is called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes two sentences: one for purpose and one for status. It is efficient, though the status note might be considered meta-information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description lacks details about return data, errors, and usage boundaries. The unavailability note is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter. The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Look up a business entity by its website domain,' which is a specific verb and resource. It distinguishes the tool's function even though it is not yet deployed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The status note indicates unavailability but does not suggest alternative tools or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
professional_lookupAInspect
Verify professional registrations across 24 Spanish health/legal/psychology verticals. Returns colegiado number, college, specialty, status.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Professional name, colegiado number, or REPS identifier |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the return values (colegiado number, college, specialty, status) but does not disclose authentication requirements, rate limits, or search behavior (e.g., exact vs fuzzy matching). Adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description adequately explains purpose, return fields, and scope. Minor omission: no mention of search behavior (e.g., partial matches) or result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already defines the query parameter's purpose. The description adds context about verticals and return fields but does not enhance parameter meaning beyond the schema. Baseline score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('verify') and resource ('professional registrations across 24 Spanish health/legal/psychology verticals'), and lists return fields. It distinguishes itself from siblings like borme_lookup or ai_ready_profile by focusing on professional registration verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for verifying Spanish professional registrations but gives no explicit guidance on when to choose this over siblings like borme_lookup or search_entities. No when-not or alternative advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_risk_auditAInspect
Run comprehensive AI-readiness + digital risk audit on any domain. Analyzes SSL, DNS, structured data, LLM visibility. Returns risk score 0-100. 5 req/min, 30s timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional business name for context | |
| domain | Yes | Domain to audit (clinicadental.es, example.com) | |
| sector_id | No | Optional sector hint (dental, legal, talleres, …) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses rate limits (5 req/min) and timeout (30s), and mentions a numeric risk score output, but does not address idempotency, side effects, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with purpose, and contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description covers the main purpose, inputs, output (risk score), and constraints (rate limit, timeout). However, missing details on the full return format (e.g., whether it returns a report or just a score) could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add detail about parameters beyond what the schema already provides (e.g., domain, optional name and sector_id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('run comprehensive AI-readiness + digital risk audit'), the resource ('any domain'), and the scope ('SSL, DNS, structured data, LLM visibility') with a specific output ('risk score 0-100'), effectively distinguishing it from siblings like 'ai_ready_profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for auditing a domain for AI readiness and digital risk, but does not provide explicit guidance on when to use it versus siblings (e.g., 'ai_ready_profile'), nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesBInspect
Search verified entities across 34 countries by name, keyword, country, or sector. Requires API key (10 req/min).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query — company name or keywords | |
| limit | No | Max results (default 10, max 50) | |
| sector | No | Sector filter (dental, legal, talleres, estetica, …) | |
| country | No | ISO country code (es, gb, fr) |
Tool Definition Quality
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 rate limit and verification aspect, but lacks details on data freshness, side effects, or authentication requirements beyond the API key mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the purpose and including only essential information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of searching across 34 countries with multiple filters, the description covers the core purpose and constraints but lacks information on response format, pagination, or error handling. The absence of an output schema makes this more noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions (100% coverage). The description adds the context of 'verified entities' but does not provide additional parameter-specific semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches verified entities across 34 countries by name, keyword, country, or sector. It is specific with verb+resource+scope, but does not explicitly differentiate from sibling tools like entity_lookup or get_full_dossier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an API key requirement and rate limit (10 req/min), which provides usage context. However, it does not specify when to use this tool versus its siblings or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_vatAInspect
Real-time EU VAT validation via VIES (27 countries). Returns {valid, name, address, vat_number, country}.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | EU VAT number (ESA28015865, A28015865, IE6388047V) | |
| vat | No | Alias for `q` — the VAT number. | |
| query | No | Alias for `q`. |
Tool Definition Quality
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 real-time behavior and VIES source, but omits details like rate limits, error handling, or authorization requirements for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence followed by a compact return format. No wasted words; front-loaded with key action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description is minimal. It leaves out details on response structure beyond fields, potential errors, country coverage, and formatting guidelines. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'Real-time EU VAT validation via VIES (27 countries)' and specifies the return fields. This is specific and distinguishes it from sibling tools like search_entities or entity_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for EU VAT validation but does not explicitly contrast with sibling tools or provide when-not-to-use scenarios. Sibling names suggest other entity-related lookups, but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zone_profileAInspect
Socioeconomic profile of a Spanish postal code — 17 blocks: income, employment, demographics, business census, real estate, FTTH, poverty, tourism.
| Name | Required | Description | Default |
|---|---|---|---|
| postal_code | Yes | Spanish 5-digit postal code (28013 = Madrid Gran Vía) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool returns 17 blocks of data, which implies a read operation, but does not disclose potential behavioral aspects like data freshness, error handling (e.g., invalid postal codes), or any constraints beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and lists key data blocks. Every word is informative, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, the description adequately summarizes the output scope by naming several data blocks. However, it lists only 7 of the 17 blocks, missing the full delineation. Given no output schema, slightly more detail would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the postal_code parameter (Spanish 5-digit code, example). The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'Socioeconomic profile' for a Spanish postal code, listing 17 specific data blocks (income, employment, demographics, etc.). This verb+resource specificity distinguishes it from sibling tools like entity_lookup or borme_lookup, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving socioeconomic data by postal code, but it lacks explicit guidance on when to use this tool versus siblings like ai_ready_profile or full_dossier. No when-not scenarios or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!