EMPORION — business facts from public registers

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 context beyond them: 'Offline, python-holidays' tells the agent the data is computed locally from a known library rather than fetched live, which explains determinism and coverage limits. It still omits error behavior for unknown country/market codes and how conflicting parameters combine.

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 with no filler, and the resource is front-loaded, but the core is a single run-on sentence with a comma-chained list of six operations that is hard to parse, followed by a bare fragment ('Offline, python-holidays'). A short structured mapping of operation-to-parameter would have been more useful at similar length.

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 8 optional parameters, no required parameters, and no output schema, the description must explain how to steer the tool and what comes back. It does list the possible outputs (working-day flag, holiday name, adjacent business days, counts, year list), which is more than nothing, but it never clarifies whether all fields return on every call or how to isolate one result, leaving real ambiguity for a multi-mode 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 75%, so the schema carries most parameter meaning (formats, ISO alpha-2, XECB/XNYS market codes, subdiv regions). The description adds operational semantics indirectly — 'date + N business days' maps to add_business_days, 'between two dates' to until, 'a year's holidays' to list_year — but never states how next/previous business day or the holiday name are requested, since no parameter appears to select them. That ambiguity caps it at baseline.

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 concrete operations on a clearly named resource: working-day checks by country/region/market (TARGET2, NYSE, LSE), holiday names, next/previous business day, date+N, day counts between dates, and year holiday lists. An agent can tell this is a calendar/holiday utility with no overlap with the sibling lookup tools. It stops short of a 5 because the enumeration is a flat list rather than a mapping of operation to triggering parameter, so the tool's exact single purpose is broad.

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 enumerated operations and by the parenthetical examples of market codes, but there is no explicit 'use this when' guidance, no statement that all parameters are optional and which combination triggers which operation, and no exclusions. With 8 optional params and 0 required, the agent is left to infer the routing rules.

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 value beyond that: it discloses the concrete response fields (name, status, legal form, founding date, address, VAT) and a data caveat — VAT only "where published" — plus register-specific fields.

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 tight sentences with the core question front-loaded, followed by a compact list of registers and returned fields. No filler; every clause 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 correctly spends its space describing returned fields and register coverage. The notable omission is how name searches behave when multiple companies match and what limit does — relevant for a tool that accepts a name plus a result cap.

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%: number and name carry their own descriptions, while limit has none and country only an enum. The description partially compensates by clarifying the two lookup modes and mapping each country to its register, but it says nothing about the limit/result-set behavior for name searches, which is the main semantic 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 states a specific verb and resource — verifying whether a company is "real and alive" via its national register by number or name — and enumerates the four covered registers (Brønnøysund, SIRENE/RNE, ARES, PRH). It does not explicitly contrast itself with siblings like vat_check or lei_lookup, so it falls short of a 5.

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 opening question "Is this company real and alive?" implies the verification use case, but there is no explicit when-to-use/when-not guidance and no mention of the alternatives in the sibling set (lei_lookup, vat_check, sanctions_screen) that could also answer company-identity questions. Usage is implied rather than instructed.

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 read-only, idempotent, open-world and non-destructive semantics, so the description's added value is in what is returned (field list) and where the data comes from (registry-sourced, not a cached WHOIS mirror). It also discloses the negative-result shape ('registered: false'), which is genuinely useful for branching logic. It does not mention rate limits or behavior for TLDs lacking an RDAP endpoint.

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?

Roughly two sentences, front-loaded with the intent question, then the field inventory and the negative case. Telegraphic but 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?

One required parameter and no output schema, so the description correctly carries the return-value burden by listing fields and the not-registered outcome. Slightly short of complete because error/edge behavior (unsupported TLD, rate limiting) is 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 coverage is 100% and the single parameter already documents normalization of URLs/subdomains to the registered name, so the description adds no parameter-level meaning. Baseline 3 applies per the schema-coverage rule.

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 verb+resource ('RDAP registration data for a domain') and enumerates exactly what comes back: created, updated, expires, age in days, registrar, status, nameservers, DNSSEC. It also names the data provenance (TLD registry located via IANA bootstrap), which no sibling tool (company_lookup, lei_lookup, vat_check) covers.

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 leading question 'Who registered this domain and when?' frames the use case clearly, and 'Or registered: false' tells the agent the tool is also an availability check. No explicit exclusions or alternatives are given, but no sibling overlaps this resource, so the gap is minor.

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, non-destructive, so the safety profile is covered. The description adds real value beyond that: the upstream data source (EC EOS), the 10-item batch cap, and the fact that name/address are only returned where the operator consented to publication — a meaningful data-availability caveat.

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 compact sentences, front-loaded with the core question, then the source and the batch/return caveats. Nothing is redundant or padded.

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 discloses what comes back (name and address, conditionally). It is nearly complete for a simple read-only lookup, though it could say what an invalid number returns and confirm the single-vs-batch input rule.

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 eoris array description already says 'or up to 10 numbers at once', and the description merely echoes the limit. It doesn't clarify the anyOf requirement (exactly one of eori/eoris) or the EORI format (country prefix + number, max 20 chars), leaving gaps the schema alone doesn't fill.

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?

Opening question states a specific verb (validate) and resource (EORI number for EU customs), and names the authoritative source (European Commission EOS). It doesn't explicitly differentiate from the closely related vat_check sibling, so it stops short of a 5.

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 validity question implies when to use it, and 'up to 10 numbers per call' hints at batch use, but there is no explicit when/when-not guidance or mention of vat_check as the alternative for tax-ID validation.

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 safety, yet the description adds real behavior: the non-trading-day fallback ('the latest ECB day on or before it, named'), the 1999 historical floor, cross-rate derivation through the euro, and Decimal precision with minor-unit rounding. It does not mention failure behavior for unknown currency codes, which is the main remaining gap.

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 tightly packed sentence with the resource and coverage window front-loaded and the dealing-rate caveat last. The stacked parentheticals ('the latest ECB day on or before it, named') make it denser than necessary but nothing is filler.

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 must imply the return shape, and it does via 'Decimal' and 'named' (the effective rate date comes back). For a four-parameter read tool this covers what an agent needs to call it correctly; only error cases and default base/quote behavior are left implicit.

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 description), so the description has to compensate, and it does: it establishes base/quote as currency pairs with cross-rate support through the euro, and explains that amount is converted and rounded to the quote currency's minor units. It never states the length-3 ISO-code constraint or the USD/EUR defaults explicitly, which is why it is not a 5.

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 resource and scope: 'ECB euro reference rate for any pair on any date since 1999', plus cross-rate and amount conversion behavior. The closing caveat 'Reference rate, not a dealing rate' disambiguates what kind of rate is returned, and no sibling tool (business_days, vat_check, etc.) overlaps with FX, so differentiation is unnecessary.

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 the use case clearly (retrieve an official reference rate for a currency pair, optionally converted), and the 'not a dealing rate' line is an explicit exclusion telling agents not to use it for tradeable quotes. It does not state exclusions for unsupported currencies or non-ECB-covered pairs, nor alternatives for a market-quote rate, so it stops short of full when/when-not guidance.

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 read-only, idempotent, open-world behavior. The description adds useful non-schema behavior: LEI check digits are verified locally, name searches return ranked candidates, and the response includes parent entities and registration details. It does not mention error handling or rate limits, but adds meaningful context beyond the 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?

The description is front-loaded with the identity question and then packs the input modes and return fields into one dense but useful sentence. Every phrase appears to earn its place, though the long parenthetical field list slightly reduces scannability.

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 lists the returned fields and explains both input modes plus local check-digit validation. It is nearly complete for a lookup tool, with the main gaps being the limit/parents parameter semantics.

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, while limit and parents only have defaults and no descriptions. The description implies ranked-candidate behavior and parent data, but does not explain the limit parameter or that parents is a boolean toggle, so compensation is partial.

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 retrieves a GLEIF LEI record and supports lookup by LEI or by legal name, making the resource and modes specific. It does not explicitly differentiate itself from the sibling company_lookup, which is the only meaningful gap for a 5.

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 implies two usage paths — exact LEI lookup versus name-based ranked candidates — but gives no explicit when-to-use guidance, exclusions, or comparison to alternatives like company_lookup. The agent can infer the modes but is not told which to prefer under what conditions.

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 the description adds substantive context beyond them: OFAC SDN carries ~500 digital-currency addresses, UN designations surface through the EU/UK entries with UN numbers, and results include each list's date and SHA-256 (provenance/versioning). It does not disclose how matching is scored, what the threshold does, or how many hits are returned by default.

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 question the tool answers, followed by list scope and output provenance. Dense but every clause carries selection-relevant information; the '~500 digital-currency addresses' parenthetical is slightly incidental but supports choosing this tool for wallet screening.

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 does some work describing hit shape (UN number, list date, SHA-256). But for a 6-parameter tool with a required-either/or input, an undocumented match threshold and unpaginated-hit behavior leave meaningful ambiguity about how results are produced and bounded.

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%; name, address, and lists are documented in-schema, and the description's note that UN entries arrive via EU/UK with a UN number usefully reinforces the `lists` semantics. However `threshold` (a fuzzy-match cutoff defaulting to 0.85), `limit`, and `kind` get no explanation anywhere, so the description does not compensate for the 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?

Opens with a concrete question ('Is this wallet address or name on a public sanctions list?') naming the resource and both accepted identifier types, then enumerates the exact lists covered. None of the siblings (company_lookup, eori_check, lei_lookup, vat_check) do sanctions screening, so the boundary is unambiguous.

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' scopes usage and warns against over-reading results, which is real guidance. It stops short of naming alternatives or stating prerequisites (e.g., which identifier to prefer when both are available), so it is clear but not exhaustive.

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 that this is a safe, read-only, idempotent, open-world lookup. The description adds useful context beyond annotations: it identifies VIES as the member-state registry, describes return information (validity, registered name/address, check time), and explains the official-proof behavior when requester_vat is supplied.

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 the core question. The second sentence efficiently covers the external source, result content, and the requester_vat proof behavior without unnecessary 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?

For a 3-parameter lookup with no output schema, the description gives enough to call it correctly and understand the main return values and proof behavior. Minor omissions remain, such as invalid-number response behavior or rate-limit/error context, but these are not critical for basic invocation.

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 the schema already documents all three parameters. The description reinforces the meaning of requester_vat and the consultation-number proof, but that meaning is already present in the schema, so it adds little beyond the structured parameter documentation.

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 a specific operation: checking whether an EU VAT number is currently valid via VIES, and it names the returned fields. It is distinguishable from siblings by domain/resource (EU VAT vs. EORI, company lookup), though it does not explicitly name sibling tools as alternatives.

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 context implies this tool is for EU VAT validation, and it explains why to pass requester_vat for a consultation number. However, it gives no explicit when-to-use/when-not guidance and does not route the agent away from near alternatives such as eori_check or company_lookup.

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