Evidence-backed company facts and current company information for company enrichment and company verification, with field-level sources, freshness and explicit conflicts. Unevidenced fields return UNKNOWN rather than a guess. $0.10 per billable call via x402; a response adding nothing beyond the identifier you supplied is free.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| domain | No | ||
| fields | Yes | ||
| max_age_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and handles it well. It discloses that unevidenced fields return UNKNOWN rather than a guess, that explicit conflicts are surfaced, that sources and freshness are included, and it even states the billing/free condition. This gives the agent accurate expectations beyond the 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?
The description is two dense sentences with no filler. The core value proposition is front-loaded, and the second sentence adds important edge-case and pricing behavior. Every clause 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?
Given 4 parameters, no output schema, and no annotations, the description is underspecified for correct invocation. It does not clarify whether name/domain is required or how they interact, what fields should contain, or how max_age_days affects results. The 'identifier you supplied' line also conflicts with the schema's optional identifier fields.
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 0%, so the description must compensate for the 4 parameters. It never maps fields, name, domain, or max_age_days to concrete usage; 'field-level sources' and 'freshness' only weakly hint at fields and max_age_days. The agent cannot infer identifier requirements or allowed field values from the text.
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 identifies the tool as providing evidence-backed company facts and current company information for enrichment/verification, with concrete output characteristics like field-level sources, freshness, and conflicts. It lacks an explicit verb like 'retrieve' and does not directly name sibling entity_evidence_validate, but it is specific and not a tautology.
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 frames when to use it: 'for company enrichment and company verification.' This gives clear context for selection. However, it does not state exclusions or compare itself to entity_evidence_validate, so it misses the top band.
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.
The two tools are clearly distinct: one performs the actual evidence retrieval, the other is a free preflight validation that retrieves nothing. No overlap or confusion possible.
Both tools share the same base 'entity_evidence' with an explicit '_validate' suffix for the preflight. This is a consistent, predictable pattern.
At only 2 tools, the surface feels thin for a domain covering both enrichment and verification. While the main tool is comprehensive, the lack of additional operations (e.g., bulk queries, field-specific requests) makes the count borderline.
The main tool delivers evidence-backed company facts with field-level detail, and the preflight covers the paywall concern. Minor gaps exist, such as no batch processing or explicit source listing, but the core verification workflow is fully covered.