ENTIA — 5.5M Verified Entities for AI Agents
Server Details
13 tools: entity lookup, BORME, EU VAT (VIES), GLEIF, healthcare & economic data. 10 countries.
- 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.6/5 across 13 of 13 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes (e.g., entity_lookup vs. get_full_dossier vs. ai_ready_profile), but some overlap exists between search_entities and get_competitors, and between entity_lookup and get_entia_home. Descriptions are clear enough to differentiate.
Naming conventions are mixed: some use 'get_' (get_competitors, get_full_dossier), others use plain verbs (verify_vat, run_risk_audit) or nouns (ai_ready_profile, zone_profile). No consistent pattern, making it harder to predict tool names.
13 tools is well-scoped for a business entity verification platform. Each tool covers a specific aspect (lookup, competitors, risk audit, VAT, etc.) without unnecessary bloat.
The tool set covers key entity operations: lookup, search, competitors, dossier, VAT validation, risk audit, and geographical profiling. Minor gaps exist (e.g., no tool for entity history or direct CIF lookup beyond entity_lookup) but overall comprehensive.
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 provided, the description carries the full burden. It discloses the output structure (4-node @graph) and purpose, but does not mention any side effects, authorization needs, or whether it makes external calls. The behavior is mostly implicit.
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 long, front-loaded with the core purpose, and contains no fluff. 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?
Given the single parameter and lack of output schema, the description is fairly complete: it specifies the output structure and intended use. However, more context about the tool's niche among many siblings (e.g., how it differs from zone_profile) would be beneficial.
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 description does not add new information about the 'query' parameter beyond what the schema already states ('Company name or domain'). No additional semantics are provided.
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 JSON-LD profile with a specific 4-node @graph structure. It highlights 'AI-ready' and 'direct AI citation', which differentiates it from siblings 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 phrase 'Designed for direct AI citation' gives a hint about usage context, but there is no explicit guidance on when to choose this tool over similar siblings (e.g., get_full_dossier, zone_profile). No exclusion criteria 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.
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 discloses a key behavioral trait: output differs based on authentication (free vs authenticated callers). This is beyond what annotations would provide. However, it does not mention rate limits, error handling, or behavior with ambiguous names.
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: first sentence states core function, second adds behavioral nuance. No unnecessary words, front-loaded with 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 the authentication-dependent behavior but lacks information on return format, exact vs fuzzy matching for name, and differentiation from sibling tools. Given no output schema and no annotations, more context would be needed for complete understanding.
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 detailed parameter descriptions. The tool description does not add new meaning beyond what the schema already provides; it repeats the identifier types. Per guidelines, 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 specifies the verb 'look up' and the resource 'any business entity', and lists specific identifiers (name, CIF/NIF, EU VAT, LEI). It distinguishes from siblings like search_entities (fuzzy search) and get_full_dossier (full dossier) by focusing on single entity lookup by exact identifiers.
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 quick identity lookup but does not explicitly state when to use this tool instead of alternatives like search_entities or get_full_dossier. No guidance on prerequisites or when not to use it.
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?
With no annotations, the description must fully disclose behavioral traits. It mentions ranking and matching criteria but omits details such as result limits, authentication needs, error behavior, or read-only nature. This minimal disclosure is insufficient for a tool with no other documentation.
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, both front-loaded and without unnecessary words. Every sentence adds value: first states purpose, second elaborates on matching logic. No wasted 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 the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks usage guidance, parameter details, and behavioral traits. While it covers the core purpose, it leaves significant gaps for an agent to select and invoke 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?
Schema description coverage is 67%, and the description adds no new parameter meaning beyond the schema. The limit parameter lacks a description in both schema and description. The description mentions sector and geography but does not provide format details or constraints, failing to compensate for the coverage gap.
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 'Find', the resource 'competitors', and the criteria 'same sector and geography'. It also mentions ranking, which adds specificity and 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?
No guidance is provided on when to use this tool versus alternatives. The description implies its use for finding competitors but does not mention when not to use it or provide context about prerequisites or exclusions.
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 the Schema.org JSON-LD @graph for a specific entity's Entia Home (machine layer at /v1/identity/{country}/{sector}/{city}/{slug}.jsonld). Requires country, sector, city, slug path segments — not cif/q. Obtain the path via entity_lookup / showcase (canonical_url). Fail-closed: never returns ENTIA corporate marketing as if it were the entity.
| 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 full burden. It discloses the output structure (4 specific nodes) which adds transparency. However, it fails to state that the operation is read-only, idempotent, or what happens when the entity does not exist. The verb 'Retrieve' implies safety, but explicit statement would improve 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 of 18 words. It immediately conveys the core purpose and the exact content of the return value. No superfluous information, making it highly concise for quick agent comprehension.
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 adequately explains the return value's structure (4 nodes). Parameters are fully documented in the schema. However, it does not mention error conditions or the meaning of 'Entia Home page'. Overall, it is mostly complete for the tool's simplicity, missing only minor behavioral context.
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 (city, slug, sector, country) have descriptions in the input schema with 100% coverage. The tool description adds no additional semantics beyond what the schema provides; it does not explain how parameters uniquely identify the entity or form the request URL. Baseline 3 is appropriate as schema already covers 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 the tool retrieves a full Schema.org JSON-LD @graph for an entity's Entia Home page, specifying the four nodes included. This is a specific verb+resource combination. While it distinguishes from siblings like 'search_entities' or 'get_full_dossier' by focusing on structured data for a home page, it does not explicitly differentiate from similar retrieval tools like '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. The description does not mention preferred contexts, exclusions, or prerequisites. Given the sibling tools list, there is no indication of when this tool is more appropriate than e.g., 'ai_ready_profile' or 'entity_lookup'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entity_home_projectionAInspect
Read the materializer snapshot entia.entity_home_projection.v1 for an Entia Home (claims + projection + policy). Same truth as the public ficha HTML/JSON-LD twin. Serve from R2 sibling .projection.v1.json — no ad-hoc MCP enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug (madrid, barcelona) | |
| slug | Yes | Business slug (clinica-dental-ceodent) | |
| sector | Yes | Industry slug (dental, legal, …) | |
| country | Yes | ISO 3166-1 alpha-2 (es, gb, fr) | |
| include_render_context | No | If true, keep render_context (large). Default strips it for agents. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read nature, data source (materializer snapshot), and serves from R2 without enrichment. Lacks details on error handling or side effects, but sufficient given 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 focused information, no filler. Could be slightly more concise but still 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?
No output schema provided; description mentions components but not structure or pagination. Adequate for a domain-aware agent but not fully complete for arbitrary use.
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 already covers all 5 parameters with descriptions. Description adds context about 'claims + projection + policy' but does not significantly enhance parameter meanings beyond 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?
Clearly states it reads a materializer snapshot for an Entia Home with specific components (claims, projection, policy). Distinguishes from public ficha twin and notes it's served from R2 without ad-hoc enrichment, differentiating from siblings like get_entia_home.
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 guides usage by equating to public ficha twin and noting the data source, but does not explicitly state when to avoid or compare to alternatives like get_entia_home.
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 parallel aggregation from 4 sources, but with no annotations, it omits failure handling, rate limits, or output format details.
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 front-loading the core aggregator function and use case with no 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?
Explains input flexibility and provides output scope (90+ fields), though lacks error behavior 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 already covers the single parameter with its description; the tool description adds no extra semantic meaning.
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 aggregates 90+ fields from 4 sources for due diligence, distinguishing it from simpler lookup tools like entity_lookup or zone_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?
Implies use for due diligence/KYB but doesn't specify when to avoid it or name alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_platform_statsCInspect
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 are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. The description merely lists output fields, lacking context about data freshness or latency.
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 that lists key data points. It is front-loaded and contains no redundant words. However, it could be slightly more structured to better assist an agent.
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 no parameters, no output schema, and no annotations, the description is minimally adequate. It explains expected output fields but does not clarify data freshness, source, or format. A bit more context would improve 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?
The tool has no parameters (schema coverage 100% for empty schema). Per rubric, baseline is 3. The description adds no parameter-level detail but is not required to. It provides context about what statistics are returned.
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 platform statistics listing entities count, countries, sources, and homes published. The tool name 'get_platform_stats' provides the verb, and the description specifies the content. However, it does not explicitly differentiate from siblings like 'get_entia_home' or 'get_showcase' 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 provides no guidance on when to use this tool versus alternatives. It does not state use conditions or exclusions. For example, an agent might not know if this is for current counts or historical data.
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?
With no annotations, the description carries full burden. It discloses it is curated and free, but does not detail output format, number of examples, or any limitations. More specifics on behavior would enhance 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?
Two sentences with no waste. The first sentence states purpose, the second highlights key features. Information is front-loaded and 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?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It covers purpose, cost, and use case. Minor omission: details on output structure or number of examples could improve 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?
There are no parameters, and schema coverage is 100% trivially. The description adds no parameter information, which is acceptable as none exist. Baseline 3 applies due to high schema coverage.
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 IBEX35 and EU entity examples, with the verb 'explore' and the resource 'data depth'. It distinguishes itself from sibling tools by being a showcase of pre-built examples rather than a lookup or search 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 mentions it is free and does not consume quota, guiding usage when exploring without cost. However, it lacks explicit when-not-to-use or alternative tool references, which would improve guidance.
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?
With no annotations, the description must disclose behavioral traits. It states the tool verifies registrations and returns key fields, implying a read-only lookup, but does not mention side effects, authorization needs, or rate limits. 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?
A single, front-loaded sentence that efficiently conveys purpose, scope, and output. No unnecessary 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 and a single parameter, the description covers the tool's core function, supported verticals, and return fields. Minor gaps exist (e.g., error handling or confidence), but overall sufficient for a straightforward lookup 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 input schema already fully describes the 'query' parameter as a professional name, colegiado number, or REPS identifier. The description adds no further parameter meaning beyond restating output fields.
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 action ('Verify'), a specific resource ('professional registrations'), and provides scope ('across 24 Spanish health/legal/psychology verticals'), which 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 the tool is for verifying Spanish professional registrations but offers no explicit guidance on when to use it vs. alternatives or situations to avoid. Context from sibling tools is not addressed.
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?
No annotations provided. The description discloses rate limit (5 req/min) and timeout (30s), adding credibility. However, it does not mention permissions, error handling, or whether the audit is destructive.
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 efficient sentences: first states purpose and scope, second details technical constraints. No wasted words, front-loaded with key 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?
Describes outputs (risk score) and rate limits but lacks details on error cases, result structure, or how to interpret the score. Without output schema, more description would be helpful.
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 clear parameter descriptions. The description adds context about what is analyzed (SSL, DNS, etc.) but does not significantly enhance understanding of parameters 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 the verb 'run', the resource 'AI-readiness + digital risk audit on any domain', and lists specific analyses (SSL, DNS, structured data, LLM visibility) and output (risk score 0-100). It distinguishes itself from siblings by being comprehensive.
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 explicit guidance on when to use this tool vs. alternatives like ai_ready_profile or entity_lookup. The description implies it's comprehensive but does not set boundaries or mention when not to use it.
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?
With no annotations, description carries full burden. It discloses auth-dependent behavior (preview vs full records) and scope (10 countries). For a non-destructive search tool, this adds valuable context beyond schema.
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 and filters, second sentence with behavioral context. No filler. Every sentence 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?
Covers search purpose, filters, scope (10 countries), and auth behavior. Missing details on result ordering and pagination, but adequate for a search tool without 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 has 100% description coverage for all 4 parameters. Description reiterates search criteria (name, keyword, country, sector) but does not add significant new meaning beyond what the schema provides. 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?
Description clearly states 'Search verified entities across 10 countries by name, keyword, country, or sector', giving specific verb and resource. It distinguishes from siblings like 'entity_lookup' (likely by ID) and 'get_full_dossier' (full detail) but does not explicitly differentiate.
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?
Provides context on authentication levels ('anonymous callers get trace preview; authenticated TRACE+ keys unlock full records'), which helps with usage. However, no explicit guidance on when to use this versus sibling tools like 'entity_lookup' or 'search_entities' (if there are multiple search tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_vatBInspect
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 does not disclose behavioral aspects such as rate limits, authentication requirements, potential delays from real-time VIES lookup, or error handling 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 a single concise sentence followed by the return structure. It conveys essential information without verbosity, though adding a list or clearer separation of return fields might improve readability.
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 validation tool with no output schema, the description informs about the external source (VIES), geographic scope (27 countries), and return fields. However, it omits details on handling of invalid numbers, connection issues, or the exact format of the response.
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 adequate descriptions for each parameter. The description adds context (VIES, 27 countries) but does not further clarify parameter meaning beyond what the schema already provides. 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 explicitly states it performs real-time EU VAT validation via VIES, mentions the 27-country scope, and lists exact return fields. This clearly distinguishes it 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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, limitations, or exclusion criteria. It states what the tool does but not when it is appropriate.
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 lists data blocks but does not disclose behavioral traits like data freshness, response size, rate limits, or whether results are cached. For a tool with no annotations, more behavioral disclosure 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?
Single sentence front-loads the purpose and key data blocks with no wasted words. 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?
With no output schema and no annotations, the description could be more complete. It lists blocks but lacks details on how to interpret results or handle errors. Adequate but has gaps.
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% (parameter has pattern and example). The description adds value by listing the 17 data blocks beyond what the schema provides, giving context on output content.
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 of a Spanish postal code, listing 17 specific data blocks. It distinguishes itself from sibling tools like entity_lookup or get_full_dossier by focusing on location-based socioeconomic data.
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 getting socioeconomic data by postal code but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites 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!