ENTIA Entity Verification
Server Details
5.5M verified entities, 10 countries, 13 tools. EU VAT, BORME, GLEIF, KYB. Free 100/mo.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ENTIA-IA/entia-mcp-server
- GitHub Stars
- 1
- Server Listing
- ENTIA Entity Verification
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.6/5 across 13 of 13 tools scored. Lowest: 2.9/5.
Most tools have clearly distinct purposes, but entity_lookup and get_full_dossier overlap somewhat, as both retrieve entity information. However, descriptions clarify that get_full_dossier is an aggregator combining multiple sources, reducing ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_competitors, verify_vat), making it easy to predict functionality from name alone.
With 13 tools, the set is well-scoped for an entity verification platform, covering lookup, search, verification, risk audit, and platform stats without unnecessary bloat.
The tool surface covers the full range of entity verification needs: multiple lookup methods, detailed dossiers, competitors, risk audits, professional verification, VAT validation, and zone profiles. No obvious gaps remain for the stated domain.
Available Tools
13 toolsai_ready_profileBInspect
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?
No annotations are provided, and the description discloses no behavioral traits such as rate limits, authentication needs, or side effects. It only states output characteristics, leaving the agent uninformed about operational behavior.
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 front-loaded, with no redundant phrases. It efficiently communicates the core purpose, though it could be slightly more detailed without losing conciseness.
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 a single parameter and no output schema, the description is adequate but lacks details on return format or error handling, leaving the agent with partial understanding 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?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema's existing description of the 'query' parameter. Baseline score of 3 applies.
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 returns a JSON-LD profile with a specific 4-node graph structure, distinguishing it from generic lookups by emphasizing 'AI-ready' and 'direct AI citation'.
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 AI citation but provides no explicit guidance on when to use this tool over siblings like entity_lookup or get_full_dossier, missing alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
entity_lookupBInspect
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 provided, the description carries the full burden. It discloses that free callers get a trace-level preview and authenticated callers get the full dossier, indicating authentication and cost implications. However, it does not state whether the tool is read-only or discuss any 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?
The description is concise with two sentences, front-loading the main purpose. It avoids unnecessary words but could benefit from a more structured format (e.g., bullet points) for clarity.
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 lack of an output schema, the description partially explains the return values (preview vs dossier). However, it does not cover response structure, error handling, or pagination, leaving gaps for an AI agent to fully invoke and handle the tool correctly.
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 has 100% coverage with descriptive parameter descriptions, including format examples for q. The description adds little beyond the schema; it mentions output behavior but not parameter details. Thus, the schema does the heavy lifting, earning a 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 verb 'look up' and the resource 'business entity' with specific identifiers (name, CIF/NIF, EU VAT, LEI). It also differentiates between free and authenticated callers. However, it does not explicitly distinguish this tool from siblings like search_entities, which might serve a similar purpose.
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 lacks explicit guidance on when to use this tool versus alternatives such as verify_vat or professional_lookup. It does not mention prerequisites, exclusions, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_competitorsBInspect
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, so the description must convey behavioral traits. It mentions ranking and matching, but does not disclose if the tool is read-only, whether it supports pagination, rate limits, or what 'real' means. The behavioral information is minimal and insufficient for a safe agent invocation.
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 is front-loaded with the core purpose. Every word adds value, with no unnecessary elaboration. It is highly efficient and scannable.
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 has 3 parameters, no output schema, and no annotations, the description is too brief. It does not describe the return format, pagination, error handling, or expected behavior when no competitors are found. A more complete description would help the agent understand what to expect.
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 have descriptions, limit does not). The description adds context for sector and city ('same sector and geography', 'identity + location + sector matching'), but does not explain the 'limit' parameter or its default behavior. Since coverage is high, a baseline of 3 is appropriate, though the description adds moderate value.
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: finding real competitors based on sector and geography. It uses specific verbs ('Find') and resources ('competitors') and includes criteria (identity, location, sector matching). This distinguishes it from sibling tools like search_entities or entity_lookup which are more general.
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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for competitive analysis in a specific sector and city, but lacks any 'when not to use' or references to sibling tools like search_entities for broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entia_homeAInspect
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 provided, so the description carries the burden. It discloses the output structure (4 nodes of JSON-LD) and the action is read-only, but it does not mention authorization needs, error conditions, or whether multiple calls are needed. Basic transparency 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?
A single concise sentence front-loads the core action and output structure. No redundant phrases; every word 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?
The description fully covers what is retrieved (4 nodes) and the tool's purpose. However, with no output schema and no annotations, additional details like response example or pagination would improve completeness. Still, it gives sufficient context for a straightforward retrieval 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?
All four parameters have descriptions in the schema (100% coverage). The tool description adds no extra semantic detail beyond referencing 'Entia Home page', which weakly links parameters to the domain. Baseline score of 3 is appropriate as the schema already documents the params adequately.
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 retrieves a full Schema.org JSON-LD @graph for an entity's Entia Home page, specifying the four nodes included. This verb+resource combination is specific and distinguishes it from sibling tools like get_showcase 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?
No guidance on when to use this tool versus alternatives such as get_full_dossier or ai_ready_profile. The description does not mention prerequisites, contexts, or exclusions, leaving the agent without decision support.
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?
Discloses that it combines 4 sources in parallel, indicating concurrent requests. However, with no annotations, it lacks details on failure handling, response size (90+ fields not detailed), performance implications, or any destructive behavior. Adequate but not 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?
Two concise sentences deliver high-value information: aggregator nature, field count, data sources, and use case. No redundant words; every sentence earns its place.
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 exists, yet the description fails to summarize categories of the 90+ fields (e.g., financial, legal, identity). Does not mention pagination, error states, or how to interpret results. Leaves significant unknowns despite tool complexity.
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?
Single query parameter is well-described in schema (company name, CIF/NIF, EU VAT, or LEI). Description adds no extra semantic detail; schema coverage is 100%, 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?
Clearly states it's an aggregator that combines 4 ENTIA sources to produce 90+ fields, explicitly positioning it for due diligence/KYB. Distinguishes from sibling single-source tools like borme_lookup or verify_vat.
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?
Implicitly suggests use for comprehensive due diligence via 'Killer tool for due diligence/KYB', but does not explicitly contrast with alternatives or provide when-not-to-use conditions. Context from sibling names helps but description could be more directive.
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?
No annotations exist, so the description bears full responsibility. It mentions 'live' but does not disclose data freshness, caching, rate limits, or whether the operation is read-only. Insufficient for agents to understand side effects or restrictions.
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?
Extremely concise single sentence with no wasted words. All content is directly relevant to the tool's purpose.
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?
The description covers basic purpose but lacks details on return format, data granularity, or any behavioral constraints. Given no output schema, additional context would help an agent interpret results.
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 has zero parameters, so the description does not need to elaborate. The baseline for no parameters is 4, and the description adds no further parameter info but is not expected to.
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 retrieves live platform statistics and lists specific data types (entities count, countries, sources, homes published). This distinguishes it from sibling tools that focus on entity lookups, dossiers, or audits.
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 on when to use this tool versus alternatives, such as when needing aggregated stats versus detailed entity data. No prerequisites or context provided.
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 are provided, but the description discloses that the tool is free and does not consume quota, which is positive behavioral context. It does not describe output format, but given no output schema, 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, front-loaded with purpose. Every word earns its place. Highly 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?
For a showcase tool with no parameters and no output schema, the description fully covers the essential context: what it provides, that it's free, and how to use it.
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 zero parameters, so the description has nothing to add. Baseline 4 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 the tool provides curated examples of IBEX35 and EU entities, and notes it is free and does not consume quota. This distinguishes it from sibling search/lookup tools.
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 'Use to explore data depth', indicating it is for exploration rather than specific lookups. However, it does not mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_by_domainCInspect
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 provided. The description notes the tool is 'Coming in v1.2 — endpoint not yet deployed,' which discloses unavailability but does not cover typical behavioral traits such as safety, permissions, 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 with clear purpose and a separate status note. No fluff, but the status note could arguably be integrated or placed elsewhere.
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?
Adequately describes a simple lookup with one parameter. Lacks guidance on when to use vs siblings and does not cover return values (no output schema described).
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%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description for 'domain' (which already specifies format).
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 states a clear verb and resource: 'Look up a business entity by its website domain.' However, it does not differentiate from sibling tools like entity_lookup or search_entities, and the status note about v1.2 adds context but no distinction.
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 on when to use this tool versus alternatives. The only context is the disclaimer that it is not yet deployed, which is a status update rather than usage advice.
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 must disclose behavioral traits. It mentions return fields but does not specify whether the operation is read-only, authentication needs, rate limits, or error conditions. Minimal behavioral context beyond basic function.
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 efficiently conveys purpose and output with no redundancy. Could be slightly more structured, but is concise and 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 the tool has one parameter and no output schema or annotations, the description adequately covers its function and expected output. It specifies the regional scope and verticals. For a simple lookup, this is sufficient.
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 single parameter described as 'Professional name, colegiado number, or REPS identifier'. The tool description adds no new semantic depth to the parameter, 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 the tool's function: verifying professional registrations across specific Spanish verticals. It lists the returned fields (colegiado number, college, specialty, status), distinguishing it from sibling tools like entity_lookup or borme_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 verifying professional registrations but does not explicitly state when to use it versus alternatives or provide exclusion criteria. Context is clear, but lacks explicit guidance.
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, the description fully discloses behavior: it analyzes SSL, DNS, structured data, LLM visibility, returns a risk score 0-100, and has rate limits. This is comprehensive transparency.
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 concise, front-loading purpose, then listing key aspects and constraints. Every sentence adds value with no waste.
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?
The description covers input, action, output (risk score), and constraints. It is nearly complete, but missing output format (e.g., JSON) which would be helpful given no output schema.
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%, so baseline is 3. The description adds no extra meaning beyond the schema; it mentions domain and audit scope but does not elaborate on parameter details.
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 runs a comprehensive AI-readiness and digital risk audit on any domain, analyzing multiple aspects and returning a risk score. It distinguishes from sibling tools by specifying the audit scope.
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 notes rate limits (5 req/min, 30s timeout) but does not explicitly state when to use this tool over alternatives or when not to use it. Usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesAInspect
Search verified entities across 10 countries by name, keyword, country, or sector. Anonymous callers receive a trace-level preview (name + city); authenticated TRACE+ keys unlock full records.
| 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 of disclosure. It clearly reveals the crucial behavioral distinction: anonymous callers see only a preview (name+city), while authenticated TRACE+ keys get full records. This is a key constraint on output based on auth level, which is well-disclosed.
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, each earning its place. The first sentence defines purpose and scope; the second adds the critical auth-level behavior. No redundancy or filler—exemplary conciseness.
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 search tool with no output schema and 4 parameters, the description covers purpose and auth levels but lacks details on result ordering, pagination beyond the limit parameter, error handling, or query language (e.g., exact match vs. fuzzy). Sibling tools like entity_lookup exist, yet no guidance on when to use each. Moderate 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%, so the baseline is 3. The description adds little beyond the schema—it enumerates the same dimensions (name, keyword, country, sector) but doesn't clarify parameter syntax, default behavior for optional params, or interactions (e.g., combining filters). It meets the minimum but does not enhance parameter understanding.
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 searches verified entities, specifies search dimensions (name, keyword, country, sector), and explicitly mentions the geographic scope (10 countries). This distinguishes it from siblings like entity_lookup (direct lookup) and get_full_dossier (detailed report).
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 does not provide explicit guidance on when to use this tool versus alternatives. While it contrasts anonymous vs. authenticated usage, it doesn't advise against using it for specific tasks (e.g., exact ID lookup vs. search). Sibling tools like entity_lookup and get_full_dossier suggest different use cases, but the description lacks 'when-to-use' or 'when-not-to-use' statements.
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 must carry the burden of behavioral disclosure. It only states it is 'real-time' and returns specific fields, but omits details like rate limits, authentication requirements, or potential errors. This is insufficient for a tool with no annotations.
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 with no extraneous information. The first defines the operation and source, the second the output format. Highly efficient.
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?
The tool is simple and schema covers parameters fully. The description explains purpose and return structure. However, with no annotations, brief mention of behavior (e.g., real-time) is helpful 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 coverage is 100% with each parameter described. The tool's description adds no additional meaning about parameters beyond the schema, resulting in a baseline score 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?
Clearly states the tool performs real-time EU VAT validation via VIES for 27 countries. The verb 'verify' and resource 'VAT' are specific, and the description distinguishes it from sibling tools like entity_lookup or get_competitors.
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 when EU VAT validation is needed but does not explicitly state when to use or avoid, nor does it mention alternatives. Since no siblings directly overlap, implied usage is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zone_profileBInspect
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?
With no annotations provided, the description alone is expected to disclose behavioral traits. It lists the data categories but does not explain the output format, whether it is read-only, or any constraints like data freshness or geographic scope. This is insufficient for full transparency.
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 that immediately states the core purpose and lists key data blocks. No unnecessary words or repetition.
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 single required parameter and no output schema, the description provides a good overview of the tool's output (17 blocks of socioeconomic data). It could be slightly improved by mentioning that it only works for Spanish postal codes (implicit in schema pattern) or typical use cases, but it is largely complete for a straightforward 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?
Schema coverage is 100% and the schema already describes the parameter well. The description repeats 'Spanish postal code' but adds no new semantic detail about the parameter itself; it focuses on output. 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 the tool provides a 'socioeconomic profile' for a 'Spanish postal code', and lists the 17 data blocks included. This specific verb-resource combination distinguishes it from sibling tools like 'entity_lookup' or 'get_full_dossier' which are more general.
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 given on when to use this tool versus alternatives, or when not to use it. The description only states what it does without any contextual recommendations or exclusions.
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!
Your Connectors
Sign in to create a connector for this server.