get_full_dossierAggregator — 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 |
| Name | Required | Description | Default |
|---|---|---|---|
| _meta | No | ||
| found | No | ||
| query | No | ||
| entity | No | ||
| integrity | No | ||
| provenance | No | ||
| trust_score | No | ||
| verification | No | ||
| data_coverage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive). The description adds useful context about parallelism and multi-source aggregation, but does not disclose potential latencies, failure semantics, or whether partial source failures affect the result. This is acceptable but not rich.
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 compact and front-loaded with the core value proposition. The 'Killer tool' phrasing is informal and adds little factual value, but the overall length is well suited 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?
Given an output schema exists and the only input is fully documented, the description covers the essential context: aggregation of sources, field volume, and intended use case. It is slightly thin on alternative routing and behavioral caveats, but nothing critical is missing for an agent to invoke it 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 schema already fully documents the single query parameter, including accepted formats (Company name, CIF/NIF, EU VAT, LEI). The description adds no additional parameter-level guidance beyond referring to 'an entity,' so a 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 this is an aggregator that returns 90+ fields about an entity by combining four named ENTIA sources. It distinguishes itself from simpler lookup tools through the aggregator framing and 'due diligence/KYB' positioning, though it does not name a specific sibling alternative.
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?
It communicates a clear target use case — 'due diligence/KYB' — and implies a comprehensive one-call need. However, it does not explicitly state when not to use it, what simpler tools to prefer for narrower queries, or where it fits relative to entity_lookup, search_entities, or verify_vat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct purposes: entity lookup vs. full dossier vs. VAT verification vs. professional lookup are clearly different. However, get_entia_home and get_entity_home_projection are very similar (both about Entia Home) and could cause confusion, though descriptions clarify the difference. Overall, overlaps are minimal and well-described.
The naming mixes conventions: 'get_' prefix is used for 8 tools, but others like 'entity_lookup', 'professional_lookup', 'zone_profile' use noun phrases without a verb. 'run_risk_audit' and 'verify_vat' are verb-based but follow different patterns. The inconsistency could confuse an agent expecting a uniform verb_noun structure.
With 12 tools, the server covers a broad but well-scoped domain of entity verification and business intelligence. Each tool serves a clear purpose, and the count is neither too sparse nor overwhelming for the intended functionality.
The tool surface covers core entity lookup, search, dossier, VAT, professional verification, and even added value like risk audit and zone profiling. Minor gaps exist (e.g., no tool for updating entity data), but for a read-heavy verification service, the set is comprehensive and leaves few dead ends.