EMPORION — business facts from public registers

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive and open-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact: the results are computed offline from python-holidays, i.e. a deterministic bundled dataset rather than a live service. However, this also sits awkwardly against openWorldHint=true, and nothing is said about data freshness or coverage limits.

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?

It is compact and front-loads the topic, with no filler. But the capabilities are a comma-spliced list without verbs or grouping, and the trailing 'Offline, python-holidays.' reads as implementation shorthand rather than agent-facing guidance. Dense but imperfectly structured.

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 an 8-parameter, zero-required, multi-mode tool with no output schema, the description lists what can be asked but not how the parameters compose, what the defaults produce, or what a response looks like. It is enough to know the tool exists and roughly what it answers, but not enough to call it confidently in mode-heavy cases.

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 75% and two parameters (list_year, add_business_days) carry no description at all; the description's phrases 'a year's holidays' and 'date + N business days' partially compensate by hinting at those two. It still does not explain the mode structure — that 'market' replaces 'country', or that 'until' and 'add_business_days' are alternative modes — leaving valid combinations ambiguous. Baseline 3 for high coverage with marginal added 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 enumerates the concrete capabilities (is-this-a-working-day, holiday name, next/previous business day, date + N, business days between dates, a year's holidays) on a clearly named resource: business days/holidays. An agent can tell immediately what domain the tool covers. There is no explicit verb and no sibling differentiation, but the siblings (company_lookup, fx_rate, vat_check, etc.) are unrelated, so distinction is not needed.

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?

Usage is only implied through the list of use cases; there is no explicit when-to-use / when-not statement and no guidance on selecting modes. Critically, the description never maps a use case to the parameter set that triggers it (e.g. 'a year's holidays' -> list_year, 'date + N' -> add_business_days), so the agent must infer mode selection. Implied usage with clear gaps = 3.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real value beyond that: the data comes from official national registers, the returned field set is enumerated, and the caveat 'VAT number where published' plus 'the register's own fields' signals that availability varies by country and registry.

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 the core question and followed by scope and output fields; nothing is wasted. The rhetorical question opener is slightly gimmicky and the trailing field list is a long run-on, but overall it is compact and readable.

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, the description usefully describes the return fields (name, status, legal form, founding date, address, VAT, plus registry-specific fields). The remaining gap is the limit parameter and whether a name search yields multiple ranked matches, which the default of 5 implies but the description never confirms.

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 50%: the number and name params are documented in-schema (including identifier formats per country), but limit is undocumented anywhere. The description confirms lookup 'by number or name' and ties countries to registers, which corroborates the schema but adds no new semantics for the undocumented limit or result-count behavior.

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?

States a specific capability — verifying whether a company is real and active — against named national registers (Brønnøysund, SIRENE/RNE, ARES, PRH) and enumerates the lookup keys (number or name). This is clearly separable from siblings like vat_check, lei_lookup, or eori_check, which target different 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 (lookup by number or name against a country register) and the country list scopes it, but never states when to pick this over vat_check, lei_lookup, or sanctions_screen, nor what to do when a company is not found or when only a VAT number is available. Usage is inferable but not guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the bar is lower. The description adds real value beyond them: the data source chain (TLD registry through IANA bootstrap), the negative result shape ('registered: false'), and the cost behavior for TLDs lacking RDAP.

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?

Three short sentences, front-loaded with the intent question and then the mechanism and returned fields. A few fragments ('Or registered: false', 'costs nothing') are telegraphic but each still carries 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?

With no output schema, the description usefully enumerates the returned fields and the failure/negative case, and notes the no-cost case for unsupported TLDs. Complete enough for an agent to call it correctly, though pagination/error semantics are unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter's normalization behavior (URL/subdomain reduced to the registered name) is already documented in the schema. The description adds nothing further about the parameter, so the baseline 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?

States a clear resource (domain registration data) and the mechanism (RDAP from the TLD's own registry via IANA bootstrap), plus the fields returned. It does not explicitly differentiate from siblings, but no sibling tool covers domain registration lookups, so confusion risk is low.

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?

Usage is implied rather than stated: the framing question 'Who registered this domain and when?' suggests the lookup intent, and 'A TLD without RDAP costs nothing' hints that calling for any TLD is safe/free. There is no explicit when-to-use, when-not, or alternative named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description only needs to add context — and it does: it names the upstream EOS service, states the batch ceiling, and discloses that name/address are returned only where the operator consented to publication. 'A service that is down costs nothing' hints at failure/cost behavior, though the wording is oblique.

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?

Front-loaded with the core question and compact at three short sentences. The closing line about downtime is a slightly cryptic use of space but does convey cost information, so nothing is outright wasted.

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, the description usefully previews what comes back (name and address, conditional on publication consent) and covers the batch limit and service origin. The scalar-vs-array invocation choice is the only notable gap for an agent to resolve from the 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?

At 50% schema description coverage, the single/scalar 'eori' parameter is undocumented in both places, and the description only reinforces the array cap ('up to 10 numbers per call') that the schema already states for 'eoris'. The one-or-many shape must be inferred from the anyOf in the schema rather than being explained in prose.

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?

Opens with a specific verb+resource framing ('Is this EORI number valid for EU customs?') and names the backing service (European Commission's EOS). It is distinguishable from vat_check and lei_lookup by domain, though it never explicitly contrasts itself with those siblings.

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 rhetorical question implies the use case (validating an EORI for EU customs) and the batch hint ('up to 10 numbers per call') tells the agent how to use it. There is no explicit when-to-use/when-not framing versus vat_check or company_lookup, leaving the agent to infer the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: date snapping to the latest ECB publishing day, cross-rate derivation through the euro for non-EUR pairs, Decimal precision, and rounding of optional amount to the currency's minor units. It stops short of describing the exact response shape, which matters since no output schema exists.

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?

Front-loaded with the resource and source (ECB euro reference rate), then bounded with scope ('any pair on any date since 1999'). It is one heavily parenthesized sentence, which is dense but nearly every clause carries distinct information; the trailing caveat is short and high-value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, open-world lookup with no output schema, the description covers source, coverage window, date-fallback semantics, cross-rate mechanics, numeric precision and rounding. The one meaningful omission is the shape of the return value, which the description hints at ('in Decimal', 'named') but never states explicitly.

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 only 50% (base and quote carry no descriptions), so the description must compensate, and it does: it explains that arbitrary pairs are handled as cross rates through the euro, that amount is expressed in the base currency, and that the result is rounded to the quote currency's minor units. It omits the base=USD/quote=EUR defaults and the base-to-quote direction of conversion, which are the remaining gaps.

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?

States a specific verb-and-resource combination: it returns the ECB euro reference rate for any currency pair on any date back to 1999. It also pins the precise object returned ('reference rate, not a dealing rate'), so an agent cannot confuse it with a dealing/spot quote. Siblings are unrelated domains, so no sibling disambiguation is needed.

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 closing clause 'Reference rate, not a dealing rate' is an explicit when-not-to-use constraint that tells an agent this is unsuitable for transaction pricing. It also establishes the date-fallback rule (latest ECB day on or before the requested date) so the caller knows the result may not match the exact date. It does not name any alternative tool, but none exists in the sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/non-destructive/open-world, so the bar is lower, and the description still adds real context: local check-digit verification of the LEI before any call, ranked (not exact) name matching, inclusion of parent-chain data, and a CC0 data license. It does not describe what happens on an invalid LEI or empty result set, keeping this from a 5.

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 dense sentence, but front-loaded with the agent-relevant question 'Who is this legal entity?' followed immediately by the data source and the two input modes. The trailing output-field list and license tag are useful rather than wasteful, though the enumeration is long enough to border on inventory.

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?

There is no output schema, so the description correctly carries the return-value burden by listing the record fields. Annotations cover the safety profile, and the parent/CC0 details round it out. Missing only edge-case behavior (invalid LEI, no matches, how many candidates limit defaults to) to be fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% – lei and name are documented in the schema, while limit and parents are bare. The description partially compensates by naming 'direct and ultimate parents' (mapping to the parents flag) and 'ranked candidates' (mapping to limit), but never ties those phrases to the parameters or explains what limit=1 vs 10 changes. 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?

Names a specific resource (GLEIF LEI record) and enumerates exactly what comes back: legal name, jurisdiction, legal form, status, addresses, registration/renewal, direct and ultimate parents. It also states the two lookup modes (by 20-char LEI or by name), which distinguishes it from name-free siblings. It stops short of naming a sibling it should be preferred over (e.g. company_lookup), so it is clear but not fully differentiated.

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 'or' construction implies the two mutually exclusive entry paths that the schema's anyOf enforces, and 'ranked candidates' signals that name search is fuzzy rather than exact. There is no explicit when-to-use statement versus company_lookup or sanctions_screen, and no stated failure/precondition behavior, so usage is implied rather than guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the description is free to spend its words on what those hints cannot convey: list provenance (per-list date and SHA-256), that OFAC SDN carries ~500 digital-currency addresses, that UN designations surface through UK/EU entries with UN numbers. It omits matching behavior (how the threshold decides a hit) and any latency/rate context.

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?

Three sentences, front-loaded with the core question, then dense factual qualifiers, then the scope caveat. Every clause carries information and nothing is repeated from the schema or annotations.

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 50% schema coverage, the description should carry more of the result-interpretation burden. It handles source provenance well but leaves the scoring model (threshold) and result caps (limit) unexplained, which matters for an agent deciding whether a returned hit is meaningful.

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 50% and the description reinforces the two well-documented inputs (address, name) plus the lists enum and its UN semantics. It says nothing about the three undocumented parameters — kind, limit, and especially threshold (0.7–1.0), whose fuzzy-match meaning is the most consequential unknown for interpreting hits.

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?

Opens with a direct question-form verb+resource ('Is this wallet address or name on a public sanctions list?') and enumerates the exact data sources (OFAC SDN, EU, UK, UN). That scope is enough to separate it from every sibling, all of which are corporate/registry lookups (company_lookup, lei_lookup, eori_check, vat_check) rather than sanctions screening.

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 closing clause 'A lookup, not a compliance determination' explicitly bounds when the output is appropriate to rely on, which is unusually useful guidance for this tool class. It does not, however, name any alternative or a when-not-to-call condition beyond that scope caveat.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it names the backing registry (VIES), states what comes back (validity, registered name and address, check time, consultation number), and notes the check is free when a registry is down. Missing only failure-mode detail for invalid numbers.

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 leading question front-loads the purpose, followed by the registry and return values, then the optional-param tip and a cost note. Sentences are short and mostly earn their place, though the final sentence ('A registry that is down costs nothing') is slightly cryptic phrasing for a no-charge guarantee.

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?

There is no output schema, so the description carries the return-value burden and does so: validity, registered name and address, check time, and the consultation number. Combined with annotations covering safety and idempotency, an agent has everything needed to call this 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 coverage is 100%, so the schema already documents all three parameters, including prefix handling and the purpose of requester_vat. The description re-explains requester_vat as proof of the check in your name, which reinforces but largely restates the schema. 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?

States a precise verb and resource: validates an EU VAT number against VIES, the member state registry. This is clearly distinguishable from siblings like eori_check, lei_lookup, and company_lookup, which cover different identifiers. An agent knows exactly what this tool answers.

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?

Usage is implied by the resource (check a VAT number) and the description does explain when to pass the optional requester_vat (to obtain a consultation number). However, it never states when NOT to use this tool or names an alternative sibling for overlapping identifier checks. Adequate but with a clear gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.