eu-verify

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

With no annotations, the description fully discloses behavior: skips weekends and the 11 French holidays, uses Butcher-Meeus for movable feasts, explains mode semantics, deterministic local computation, JSON output, and price. This exceeds typical descriptions.

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 information-dense but compact; every clause adds value (behavior, modes, determinism, output, cost). It is front-loaded with the core purpose and uses concrete examples.

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 stateless calculation tool with no annotations or output schema, the description covers purpose, inputs, modes, holidays, and output type. It lacks only an explicit output shape, but 'JSON' is likely sufficient for an agent to invoke and parse.

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 0%, so the description is the only source of parameter meaning. It compensates well by explaining start/add with examples and adding from/to/mode semantics. However, the schema's required 'start' is not reconciled with the range mode using 'from', creating minor ambiguity.

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 opens with a specific verb-resource pair ('Adds N French business days') and immediately distinguishes the two calculational modes (add vs range). It is unmistakably distinct from sibling validation/lookup tools.

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 provides clear usage context with concrete URL examples and defaults ('?start=2026-07-13&add=30', mode=ouvres default). It does not explicitly name when not to use it, but the context is sufficient for an agent to select it for French business-day arithmetic.

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?

With no annotations provided, the description carries the full burden and adds useful behavioral context: 'FREE' indicates no cost, 'Lists every product' indicates exhaustive scope without filters. It also communicates a read-only discovery purpose. No contradictions with annotations exist since none are present.

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, front-loading the most important fact ('FREE') and stating the core function and purpose in an efficient manner. Every word is informative, with no fluff or 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 zero-parameter tool with an output schema, the description fully covers what the tool does, what data will be returned (endpoint, price, summary), and when to use it. The output schema handles return structure, so the description is complete for an agent deciding to invoke this 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?

The input schema has 0 parameters, so the baseline is 4. The description adds a small amount of semantic value by stating there is no filtering ('every product'), reinforcing that no parameters are needed. It does not describe parameters because none exist.

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 uses the specific verb 'Lists' with resource 'every product of this data shop' and details exact contents (HTTP endpoint, price in USDC, one-line summary). This clearly distinguishes the catalog tool from sibling data lookup tools, which serve specific data services rather than an index of them.

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 states when to use the tool: 'Use it to discover capabilities before paying.' This provides a clear usage context, though it does not explicitly mention alternatives or exclusions. It effectively guides the agent to use this first as a discovery step before selecting a specific sibling tool.

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?

With no annotations provided, the description carries full burden and excels: it discloses live upstream service (EOS/DDS2), output format (valid true/false plus name/address conditionally), transport details (SOAP upstream, clean JSON out), caching behavior (24h cache), and cost ($0.003 USDC per call). This is rich behavioral context beyond what a schema or annotations would provide.

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?

Every sentence adds value: purpose, use case, parameter format, return behavior, operational details (JSON/cache), and pricing. The description is front-loaded with the primary function and is efficiently structured, with no filler or 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?

Given the simplicity (1 param, no output schema, no annotations), the description is remarkably complete. It covers input format, expected output, conditional data availability, and cost/caching nuances. Nothing essential 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?

Schema coverage is 0%, so the description must compensate. It does so fully: 'Query: ?eori=FR38347481400100 (2-letter country + up to 15 alphanumerics)' specifies the exact format and provides an example, adding essential meaning beyond the bare schema property 'eori'.

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's purpose: 'Live EORI (Economic Operators Registration and Identification) validation via the European Commission EOS/DDS2 service.' It specifies the exact resource (EORI numbers) and the action (validation), and distinguishes it from sibling validation tools (email, IBAN, SIRET, VAT, etc.) by focusing on this unique EU customs identifier.

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 clear usage context: 'the number every business needs to clear customs in the EU' implies when to use it (validating an EORI for customs-related checks). It does not explicitly compare to alternatives or state exclusions, but the context makes the intended use case obvious. This matches 'clear context, no exclusions'.

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?

With no annotations present, the description carries the full burden and does so thoroughly. It discloses Luhn validation, GDPR-safe legal-entity-only scope, caching behavior, pricing, source frequency, and the meaning of empty results. This is rich behavioral context beyond a simple API call.

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 but information-dense. Every sentence adds value: purpose, query pattern, return contents, GDPR note, clean-record signal, source, cache, and price. No filler or redundant restating of the tool name.

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 moderate complexity (3 params, no output schema), the description is complete: it covers return fields, ordering, source, update frequency, caching, pricing, and the clean-record interpretation. It does not describe error handling for invalid SIRENs, but the Luhn-validation mention partially covers that.

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 0%, so the description must compensate, and it does: siren is explained as required and Luhn-validated with an example, famille is described as an optional filter with a concrete value, and limit is given a numeric range. Minor deduction because the description mentions limit=10 as an example while the schema default is 5, which could cause slight confusion.

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 legal announcements from the French BODACC official gazette for a single company identified by SIREN. It distinguishes itself from sibling tools like lookup_company_fr or verify_supplier_fr by focusing on BODACC legal announcements, and the optional 'famille=collective' filter ties directly to insolvency proceedings.

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 clear usage context: when to use it (checking a company's legal announcements by SIREN), the required parameter format, and an optional filter. It also explains that zero announcements for a valid SIREN is a clean-record signal, which guides interpretation. However, it does not explicitly name alternative tools for when this tool should not be used.

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?

With no annotations, the description provides essential behavioral details: data source (TED, official Publications Office API), freshness (new notices daily), caching (1h cache), and pricing ($0.01 USDC per call). It effectively conveys that this is a read-only, paid API call.

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 deliver purpose, query example, parameter explanations, output fields, caching, and pricing. Every clause has a purpose, and the key benefit is front-loaded.

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 and lack of output schema, the description covers the core: output fields, parameter meanings, caching, and pricing. It does not mention error handling or pagination, but the limit parameter and simple list response make this a minor gap.

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 description adds meaning beyond the schema by explaining cpv as 8-digit CPV code, country as 3-letter buyer country, and 'all optional'. The example query with days_back and limit gives practical context. The schema only provides names and types, so this clarification is valuable.

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's function: finding EU public procurement notices from TED (Tenders Electronic Daily), with a specific source and example query. This is a distinct capability across all sibling tools, which focus on company lookups and validations.

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 includes a concrete query example and notes that all parameters are optional, implying when to use the tool (when EU procurement data is needed). However, it does not explicitly state conditions for use or compare with alternatives, though no sibling tool overlaps in functionality.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It thoroughly explains the tool's actions: Luhn checksum validation, SIRENE registration check, VAT number computation, live VIES validation, and a fallback verdict if VIES is flaky. It also mentions 1h caching and the price per call, providing complete 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 packed with useful information in a compact form. Each sentence contributes value—purpose, query format, validation steps, output verdict, fallback behavior, caching, and pricing. It is slightly longer than strictly necessary but remains efficient and well-organized.

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 moderate complexity and the absence of an output schema, the description is remarkably complete. It covers what the tool does, how to structure the query, what the response looks like (three possible verdicts), reliability caveats, caching, and cost. This is sufficient for an agent to confidently select and invoke the 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?

The schema only defines a single string parameter 'number' with no description, so the description must compensate. It does so by explaining the accepted formats: SIREN (9 digits) or SIRET (14 digits), with concrete examples. This adds crucial semantic detail that the schema lacks.

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's purpose: a one-call compliance check for the French e-invoicing reform. It specifies the exact validation steps (Luhn checksum, SIRENE registry, VAT computation, VIES validation) and distinguishes itself from single-purpose siblings like validate_siret_fr and validate_vat_eu.

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 clear context for when to use this tool: for French e-invoicing compliance, especially after 2026-09-01 when SIREN becomes mandatory. It implies this is the go-to for a comprehensive check, though it does not explicitly state when not to use it or name alternatives.

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?

With no annotations provided, the description carries the full transparency burden. It discloses: official GLEIF source, CC0 licensing, geographic coverage (2.5M+ entities), query format, unknown LEI behavior (found=false), caching (24h), and pricing (x402). It does not mention rate limits or auth, but for a simple lookup tool this level of detail is strong.

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 information-dense, with the core purpose front-loaded ('Who owns whom') and supporting details efficiently ordered. Every sentence contributes: data source/coverage, query example, return contents, unknown behavior, and pricing. No wasted 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?

For a single-parameter tool with no output schema or annotations, the description covers all essential aspects: input format, output scope, edge cases, data provenance, caching, and cost. It is sufficiently complete for an agent to select and invoke this tool without needing additional 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?

The only parameter, lei, has zero description in the schema, so the description must compensate. It provides a concrete query example (?lei=5493001KJTIIGC8Y1R12) that demonstrates the expected format. It doesn't explicitly state the LEI standard length or validation rules, but the example gives an agent enough grounding to fill the parameter correctly.

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 uses a clear, specific framing ('Who owns whom, from the official GLEIF LEI graph') and enumerates exactly what the tool returns: entity name/status, direct parent, ultimate parent, and direct children sample. This distinguishes it from sibling tools like lookup_lei, which likely handles only basic LEI lookup.

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 when to use this tool—when you need ownership hierarchy and parent/child relationships from GLEIF—and highlights that it consolidates 'four GLEIF lookups in one call.' It does not explicitly name alternative tools or exclusion criteria, but the context is clear enough for an agent to choose it over simpler LEI lookups.

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?

No annotations are provided, but the description fully compensates by disclosing GDPR-related data stripping, 24h caching, per-call pricing, and the specific return fields (SIREN, legal form, NAF, etc.). This goes well beyond basic purpose and gives the agent important operational expectations.

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 concise at three sentences and front-loads the purpose. The parameter list in the second sentence is dense but still readable, and every sentence contributes useful information. Slightly long but appropriate for the complexity.

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?

Despite having only two schema parameters and no output schema, the description is remarkably complete. It covers the query syntax, expected return data, privacy constraints, caching, and cost, leaving little gap for an agent to invoke the tool incorrectly.

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 description explains q as a name or SIREN and notes per_page range (1-10), adding meaning beyond the schema. However, it also lists optional parameters (page, code_postal, activite_principale, etat_administratif) that are not present in the input schema, which could mislead an agent into passing invalid arguments. Thus it partially compensates but introduces ambiguity.

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 an official French company registry search, specifying the data source (recherche-entreprises.api.gouv.fr / INSEE Sirene) and what it returns. It distinguishes itself from sibling tools like lookup_company_uk by being France-specific.

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 provides clear context for when to use this tool: French company lookups by name or SIREN, with query examples and optional filters. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full exclusionary 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?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It goes well beyond a simple definition by mentioning the paid call cost ($0.01 USDC), 24h cache, data minimization, and the specific output fields including risk flags and insolvency cases. This provides a comprehensive picture of the tool's behavior and data quality.

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 well-structured and information-dense. It front-loads the key purpose, then uses examples to clarify usage, and includes pricing and caching details without wasted words. Every sentence earns its place, making it both concise and comprehensive.

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 lack of an output schema, the description must explain return values, which it does by listing fields for both search and profile modes. However, it omits details about the 'limit' parameter's behavior (e.g., default, max) and does not address edge cases like providing both 'q' and 'number'. This leaves minor gaps in 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 schema has 0% description coverage, so the description must compensate. It explains the 'q' parameter (search query) and 'number' parameter (profile lookup) with examples, but it does not explain the 'limit' parameter, which is a gap. Thus, it adds meaning for most but not all parameters, leaving the description partially compensating.

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 opens with 'Official UK Companies House data in one paid call,' which clearly states the tool's purpose and resource. It then distinguishes between search and profile modes with concrete examples, making it easy to understand what the tool does and how it differs from the sibling tools for other countries.

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 clear usage context by showing example queries for both search and profile, and implicitly indicates when to use this tool (for UK company data). However, it does not explicitly state when not to use it or name alternative tools, so it lacks explicit exclusions but has clear enough context.

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?

With no annotations, the description carries the full transparency burden and does so well: it discloses the filing history fields, the conditional accuracy policy ('says not_covered rather than guessing'), the 24h cache, and the price. This is rich behavioral disclosure beyond a simple read-only implication.

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 dense but every sentence adds value: purpose, query syntax, return fields, limitation policy, cache, and price. It is front-loaded with the core purpose and efficiently 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 a single-parameter lookup with no output schema, the description covers input validation, return elements, and fallback behavior. It could add error cases (e.g., invalid Luhn, no filings found), but the main operational behavior is sufficiently 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?

The input schema only lists 'siren' with no description, but the description compensates fully by giving the query format (?siren=), an exact example, the 9-digit length, and Luhn validation. This is more than enough for an agent to format the parameter correctly.

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 it returns annual accounts filed with the French RNE (INPI), and details the filing history plus headline financial figures. This verb+resource scope is distinct from sibling tools like lookup_company_fr or check_insolvency_fr.

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 'Annual accounts filed with the French RNE' and 'which is a KYB signal in itself' make the intended context clear—French financial/KYB checks. It does not explicitly name when-not-to-use or alternatives, so it stops short of a 5.

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?

No annotations are present, so the description carries full responsibility. It discloses the data source, update frequency, CC0 license, 24-hour cache, and per-call price, which is more transparent than typical tool descriptions. However, it does not mention any authentication or error 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 paragraph packed with essential information: purpose, example queries, result fields, cache, and pricing. It is dense but efficient, with every clause adding value and no 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?

Given the lack of output schema and annotations, the description provides a solid overview: query patterns, result structure, and operational details (cache, price, source). It lacks explicit instructions on parameter interaction (e.g., whether lei overrides search) but is reasonably complete for a 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 0%, so the description must explain parameters. It does so via concrete examples: '?lei=...' for direct lookup and '?name=airbus&country=FR&limit=5' for search, clarifying the roles of lei, name, country, and limit. It also lists result fields, but does not detail parameter constraints like case sensitivity or optionality.

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 legal entity reference data from the GLEIF LEI golden copy, with both direct lookup by LEI and search by name/country. It distinguishes itself from sibling company lookup tools by its specific data source and focus on LEI 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 LEI data lookups but does not explicitly state when to prefer this over sibling tools like lei_ownership or lookup_company_fr. It provides query examples but no alternative comparisons or exclusions.

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?

Without annotations, the description takes full responsibility for behavioral disclosure. It covers data freshness (snapshot refreshed daily), query parameter format, output details (scored matches, entity type, programs, verdict), and pricing, which goes well beyond typical descriptions.

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 information-dense sentences with no filler. The first sentence states the primary function and data source; the second covers parameters, output, and pricing—all essential and front-loaded.

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?

Despite having no output schema and no annotations, the description alone makes the tool self-contained: it explains inputs, outputs, constraints (threshold range), and cost, so an AI agent can reliably select and invoke it.

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 descriptions are absent (0% coverage). The description adds the accepted threshold range (0.6-1.0), the list codes (eu, ofac, un, uk, fr), and the query format, fully compensating for the schema's minimal titles.

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 the exact action ('Screen a name') and resource ('five official sanctions lists'), listing the specific lists and distinguishing it from sibling verification tools like check_eori or verify_company_fr.

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 narrow focus on sanctions screening makes the intended usage clear, but the description does not explicitly state when to use this tool over alternatives or include exclusions. It stops short of providing direct alternative 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?

With no annotations, the description carries full responsibility and does exceptionally well. It discloses the live MX lookup over DNS-over-HTTPS with Cloudflare/Google fallback, detection of NXDOMAIN and null-MX (RFC 7505), 1-hour caching, pricing, and verdict types. This goes far beyond what structured fields provide.

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 dense yet efficiently structured, starting with the primary purpose and then layering technical details, query format, output verdicts, cache, and pricing. Each sentence adds valuable information with no 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?

Given the absence of an output schema, the description explicitly lists the verdict values (deliverable | risky | undeliverable), mentions the return of prioritized MX hosts, and covers caching and pricing. For a single-parameter tool, this is a self-contained and complete specification.

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 only defines 'email' as a required string with no description (coverage 0%). The description compensates by showing the query format (?email=someone@example.com) and indicating the expected input is an email address through the RFC 5322 syntax check. It does not exhaustively detail edge cases, but for a single simple parameter it is sufficient.

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 it performs email verification for lead qualification and list hygiene, using a specific verb ('verification') and resource ('email'). It also outlines the process (RFC 5322 syntax check, MX lookup) and clearly distinguishes from sibling validation tools that target other entities like IBAN or VAT.

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 gives clear use cases (lead qualification, list hygiene) and a query format, but it does not explicitly mention when not to use it or name alternative tools. This is a minor gap given the obvious email-specific scope.

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?

With no annotations provided, the description carries the full burden and excels: it discloses pure offline computation, 1y cache, pricing ($0.001 USDC), return fields (valid, country, bban, failure reason), and tolerance for spaces/dashes. This fully informs the agent of behavior without requiring 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?

Every sentence adds value: purpose, algorithm, example, tolerance, return values, offline/cache, and price. It is dense yet efficient, with no repetition or filler, making it easy to scan and digest.

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 no annotations, the description comprehensively covers purpose, usage context, input format, output fields, offline behavior, caching, and pricing. This is sufficient for an agent to select and invoke the tool correctly without ambiguity.

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 input schema provides only a string parameter with 0% coverage, but the description compensates with a concrete example (?iban=FR1420041010050500013M02606) and explicitly notes spaces/dashes are tolerated. This gives the agent unambiguous guidance for constructing a valid request.

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 'Deterministic IBAN check' and details the checks (format regex, per-country length, ISO 7064 mod-97 checksum). This clearly identifies the tool's function and distinguishes it from sibling validators like validate_email, validate_vat_eu, and validate_siret_fr by name and algorithmic specifics.

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 a clear use case: 'before a SEPA/international transfer.' This contextual signal tells the agent when to invoke the tool. However, it doesn't explicitly mention alternatives or when not to use it, which is a minor omission given the tool's obvious domain-specificity.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It details the validation algorithm (INSEE Luhn rule, La Poste exception), input tolerance (spaces/dots/dashes), return fields, offline/cached computation, and pricing. This is comprehensive and leaves no hidden behavioral surprises.

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 three sentences, each packed with distinct value: usage context, validation rules, and returns/pricing. No fluff or 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?

Given no output schema, the description explicitly lists return fields (valid, type, siren, nic, rule applied) and covers input, algorithm, caching, and cost. It is fully self-contained for an agent to invoke this 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?

The schema has only a bare 'number' string parameter with 0% coverage. The description compensates fully by explaining the expected format (9 or 14 digits), tolerance for separators, and even provides an example value, making parameter usage unambiguous.

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 validates French SIREN/SIRET numbers, with a specific verb ('pre-validation') and resource ('French company numbers'). It also distinguishes itself from sibling validation tools by mentioning SIREN/SIRET and the Sirene API context.

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 explains when to use the tool ('before invoicing or costly Sirene API calls') and positions it as a cheap, offline pre-check. However, it does not explicitly contrast it with alternative validation tools like validate_vat_eu or verify_company_eu, so it stops short of full exclusion criteria.

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?

With no annotations, the description carries the full burden. It discloses that the tool performs live real-time queries, has a 24h cache, costs $0.005 USDC per call, and returns specific fields (is_valid, trader name/address, request_date). It also notes conditional behavior (trader info only when member state publishes it). This is strong behavioral disclosure despite missing rate limits or auth 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?

The description is two sentences but information-dense, front-loading the core purpose then systematically covering query format, return values, caching, and pricing. No filler or redundancy—each clause adds essential context.

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?

Despite lacking an output schema and annotations, the description explains the return fields, the API mechanics, and the pricing. It does not cover edge cases like invalid country codes or network errors, but for a validation tool this is adequate. It's nearly complete, though it could mention what happens if the VAT number is invalid or the registry is unavailable.

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. It fully explains both parameters: cc as member state code (including EL/XI) and vat as the number without country prefix, illustrated with the example ?cc=IE&vat=6388047V. This adds significant meaning beyond the bare 'country' and 'vat' property names in 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 states a specific verb+resource: 'Live intra-EU VAT number validation via the European Commission VIES REST API'. It clearly distinguishes itself from sibling tools like validate_email and validate_iban by focusing on EU VAT numbers, and even specifies the API and registry used.

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 clear context by showing a concrete query example and explaining parameter format (cc member state code, vat without prefix). It implicitly indicates when to use the tool (when an EU VAT number needs validation) but does not explicitly mention alternatives or exclusion scenarios. This is a minor gap.

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?

With no annotations, the description carries the full burden. It thoroughly discloses behavior including caching (24h), error handling (400 on no match, not billed), and pricing ($0.001 per call). It also explains the return fields, leaving little ambiguity about the tool's operation.

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 dense but every sentence adds critical operational information: purpose, forward/reverse modes, parameters, return data, error handling, caching, and pricing. It is well-structured, starting with the core functionality and then layering details.

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 many aspects: API source, input modes, parameters, output fields, error behavior, caching, and cost. However, it omits the fact that type and citycode are not actually supported by the MCP schema, and it does not mention potential rate limits. Still, given no output schema, the description is fairly 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?

The description provides meaningful detail for q (with example) and limit (range and default), which the schema lacks. However, it also describes optional parameters 'type' and 'citycode' that are not present in the input schema, creating a misleading invocation path. This inconsistency harms the agent's ability to call the tool correctly.

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 performs French address geocoding using the official Base Adresse Nationale. It distinguishes itself from sibling validation tools by focusing on geocoding, and it explicitly mentions both forward and reverse geocoding.

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 clear context for when to use the tool (French address verification/geocoding) and explains the forward and reverse API usage. It does not explicitly mention alternatives or exclusions, but the purpose is distinct enough among siblings.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently lists all checks performed, the verdict format (pass/review/fail with per-check source, timestamp, coverage map), and discloses pricing and the no-charge-on-failure policy. It also explains the query example and country coverage. Minor gaps include no mention of authentication or error handling, but overall it provides substantial behavioral 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?

The description is front-loaded with the core purpose ('One-call verification of a European company') and efficiently packs essential details: checks performed, verdict output, query example, supported countries, disclaimers, and pricing. Every sentence contributes meaningful information without redundancy, making it concise despite covering multiple aspects.

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 reasonably explains the return value as a pass/review/fail verdict with sources, timestamp, and coverage map. It also covers supported countries, expectations (factual, not credit score), and commercial terms. However, it omits details on error handling, authentication, and parameter format variations by country, which would be needed for fully autonomous 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 coverage is 0%, so the description must add meaning. It clarifies the 'id' parameter as a national registry number, provides a concrete query example (country=FR, id=552032534), and lists supported country codes. It also implies the roles of 'vat', 'lei', 'eori', and 'domain' by naming them in the verification scope. This adds value beyond the bare parameter names, though it lacks detailed format specifications for each country.

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's purpose with a specific verb and resource: 'One-call verification of a European company.' It enumerates distinct checks (registry existence, insolvency signals, VAT, LEI, sanctions screening, EORI, domain age) and distinguishes it from siblings by offering a comprehensive single-call verification rather than a single-purpose check like validate_vat_eu or check_insolvency_fr.

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 context: use this tool when you need a comprehensive, one-call verification of a European company, as opposed to calling multiple sibling tools individually. It also clarifies what the tool is not ('Factual verification, not a credit score'), setting expectations. However, it does not explicitly name alternatives or provide 'when not to use' guidance, so it falls short of a 5.

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?

With no annotations, the description carries the full burden and does well: it discloses graceful degradation of sub-checks, the 'never charged on failure' policy, the price, and the condensed verdict format. This goes beyond minimal expectations and gives the agent confidence in failure handling.

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 packed with vital information: purpose, sub-checks, input format, failure behavior, price. Every sentence earns its place, and the structure is front-loaded with the core purpose before operational details.

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?

Despite no output schema and no annotations, the description covers the purpose, input format, expected output (risk verdict with reasons and score), pricing, and failure behavior. This is sufficient for an agent to select and invoke the tool correctly without missing critical 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?

The schema has one parameter 'number' with no description (0% coverage). The description compensates by specifying the accepted formats (SIREN or SIRET) and providing the query pattern. However, the 'siren=...' phrasing could be slightly ambiguous about whether the value should include that prefix, so it's not a perfect compensation.

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 performs one-call due diligence on French companies via SIREN/SIRET, enumerating specific checks (SIRENE, BODACC, VIES, sanctions) and the output (risk verdict with score). This distinguishes it from siblings that cover only subsets, like check_insolvency_fr or screen_sanctions.

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 is clear: it is for comprehensive due diligence on French companies, including pricing and input format. However, it does not explicitly name alternatives or provide when-not-to-use guidance, such as referring to verify_company_eu for broader EU coverage.

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