nordic-data

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe, idempotent read. Description adds key behaviors: returns ranked suggestions with coordinates, covers 15 countries, and discloses subscription limitation for NL/DE with 402 error handling. No contradictions.

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?

Compact paragraph with clear flow: data source claim, output description, supported countries list, and critical tier note. Every sentence adds value with no redundancy or weak language.

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 complexity of multi-country autocomplete and presence of an output schema, the description covers sources, countries, output type (ranked with coordinates), and error handling for upgraded subscriptions. Could mention pagination or rate limits but overall sufficient for agent usage.

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?

Input schema already documents both parameters (query and country) with 100% coverage. Description adds minimal extra semantics beyond schema, such as clarifying query is partial address and country is ISO alpha-2 lowercase. Baseline 3 is appropriate as schema carries the burden.

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?

Clearly describes the tool as an address autocomplete using authoritative registers per country. Distinguishes itself from sibling tools (all company/KYB/sanctions/VAT related) by focusing on address lookup with specific country-level data sources.

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?

Explicitly states when to use (address autocomplete), lists supported countries, and provides a critical usage constraint: NL/DE require a Starter+ subscription and 402 errors should not be retried. Lacks explicit when-not-to-use or alternatives, but siblings are unrelated, so context is clear.

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 readOnlyHint, idempotentHint, and destructiveHint as true/true/false, indicating a safe, idempotent read operation. The description adds behavioral details beyond annotations: it explains the multi-source aggregation, the specific data sources (DAWA, DST, SSB, Wikidata), and the error handling for paid upstream registries (HTTP 402). This provides useful context that annotations alone do not cover.

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 four sentences, each adding value: first sentence lists data types and sources, second emphasizes efficiency, third enumerates countries, fourth provides a critical usage note. It is front-loaded with the main purpose. Some minor redundancy (e.g., 'One call, multiple sources' is already implied) but overall concise and well-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?

Given the tool has an output schema (so return values are documented separately), the description covers the key aspects: what data is aggregated, which countries are supported, and a notable error handling case (402 on NL/DE). It does not mention rate limits or authentication requirements, but annotations cover safety and idempotency. For a read-only data retrieval tool with good schema support, the description 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?

Input schema has 100% description coverage: 'id' is described as 'National company identifier — same format as lookup_company' and 'country' as 'ISO 3166-1 alpha-2 country code, lowercase.' The description adds a cross-reference for 'id' to the sibling tool 'lookup_company', which aids understanding. Baseline is 3 due to high schema coverage, but the cross-reference and clarity justify a 4.

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 'Enriched company data' and enumerates the specific data types included (basic registry, validated address, industry statistics, Wikidata enrichment). It distinguishes from the sibling tool 'lookup_company' by emphasizing the multi-source aggregation and broader scope. The purpose is clear and 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 description provides context for use: 'One call, multiple sources' implies this tool is for comprehensive data retrieval. It also includes a critical usage note about paid tiers for NL and DE, advising against retrying on HTTP 402. However, it does not explicitly state when to use this versus alternative sibling tools like 'lookup_company' or 'kyb_full', so usage guidance is present 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 indicate read-only, idempotent, non-destructive. Description adds behavioral details: cache duration, quota cost, error conditions, and data source (INSEE Sirene bitemporal array). No contradictions.

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?

Description is somewhat verbose but well-structured, each sentence provides distinct information. Could be slightly shortened without losing clarity, but overall efficient.

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 presence of an output schema (not shown but exists), the description adequately covers purpose, input, errors, caching, and data scope. It explains the types of events ('initial:' fields) and underlying array, providing sufficient context for an agent.

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 covers the parameter with description and pattern (100% coverage). Description adds value with concrete examples (Carrefour, LVMH) and explicit formatting rules (no spaces/punctuation).

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?

Description clearly states it provides a timeline of French company history events, covering changes to key attributes. It does not explicitly differentiate from sibling tools like lookup_company or company_enriched, but the purpose is specific and well-defined.

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?

Description includes input format, cost, cache, and error codes, providing some guidance. However, it lacks explicit when-use vs alternatives (e.g., when to use history vs current snapshot), so usage context is partial.

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?

Beyond annotations (readOnlyHint, idempotentHint), the description details performance (cold 10-15s, warm <100ms), caching durations (6h success, 60s partial), partial response format (truncated: true, sectionsUnavailable), and tier restrictions (402 error, quota multipliers). No contradictions with 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?

Information is front-loaded with purpose, then sections, performance, caching, partial responses, and tier notes. Every sentence is informative with no redundancy. Appropriate length 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 no output schema, the description fully explains what the report contains (9 sections), response behavior (truncated, sectionsUnavailable), performance characteristics, and error handling. Enough for an agent to use the 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?

Schema covers 100% of parameters. Description adds value by listing the 15 supported country codes and clarifying that the id format matches lookup_company, providing context beyond the schema's enum and description.

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 produces a 'Full Know-Your-Business master report' and lists the 9 specific sections aggregated. It distinguishes from siblings like lookup_company and screen_sanctions by offering a comprehensive single-call report.

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?

Provides explicit when-to-use guidance: single call vs. individual tools, partial response retry logic, and specific warnings for NL and DE paid tiers (do not retry on 402). Also clarifies caching behavior and result availability.

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 indicate the tool is read-only and idempotent. The description adds valuable behavioral context: HTTP 402 handling for free-tier NL/DE requests, cost quota differences, and that it uses official registries. No rate limits or pagination details are given, but the added context is significant.

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 moderately concise; it front-loads the core purpose and then adds necessary tier details. It could be tightened slightly but is well-organized and easy to parse.

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 output schema exists (not shown), the description covers all key aspects: purpose, supported countries, parameter format hints, free-tier restrictions, and error handling. It is complete enough for an agent to correctly 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?

Schema coverage is 100% with detailed parameter descriptions for 'id' (formats per country) and 'country' (enum). The description does not add significant new semantics beyond the schema; it only provides tier context for certain countries, which is already inferable.

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 looks up basic company data from official European registries, lists the fields (name, address, etc.) and the 15 supported countries, making the purpose very specific and distinct from siblings like company_enriched or kyb_full.

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 guidance on when to use the tool (for basic company data from 15 countries) and includes important usage notes like 'do NOT retry on 402' and cost multipliers for paid tiers. However, it does not explicitly contrast with sibling tools to help the agent choose between them.

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?

Discloses behavioral traits beyond annotations: returns relationships, supports reverse lookup across 15 countries, and explains 402 behavior. Annotations already indicate read-only, idempotent, non-destructive; description adds valuable nuance without contradiction.

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 slightly verbose but well-organized: purpose first, then data returned, then modes, then a critical note. Every sentence provides useful information; 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?

For a tool with 5 parameters (1 required), 100% schema coverage, and output schema present, the description adequately covers usage, modes, return values, and error handling. No gaps remain.

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?

Input schema has 100% coverage, so baseline is 3. Description adds value by explaining the reverse lookup scope (15 countries), the tier-dependent behavior for NL/DE, and the conditional nature of include_relationships (only applies when mode='lei').

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?

Clearly states the tool looks up a Legal Entity Identifier (LEI) via GLEIF and lists specific data returned (legal name, address, status, parent/child relationships). Distinguishes from siblings on the same server (e.g., lookup_company, company_enriched) by focusing on the global LEI standard.

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?

Explicitly describes two modes (lei and reverse) with required parameters for each. Provides critical guidance: a tier note warns that NL and DE use paid upstream registries and advises against retrying on HTTP 402, preventing wasted API calls.

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?

Beyond annotations (readOnly, idempotent), the description adds the data scale (768K+ entries) and return format (match scores with source attribution), though does not cover edge cases or detailed 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 remarkably concise: two sentences front-load the core purpose and add relevant context (data source, return format) without superfluous 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?

Given the presence of an output schema (not shown but confirmed), the description provides sufficient context for usage understanding, though it could hint at output structure or score interpretation.

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?

All three parameters are fully described in the schema (100% coverage), and the description adds no further parameter-specific context, so baseline score 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?

The description clearly states the tool screens names against specific sanctions lists (UN, EU, OFAC, PEP) via OpenSanctions, distinguishing it from sibling tools like company_enriched or validate_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?

No explicit guidance on when to use this tool versus alternatives, though the context of sibling tool names implies its use for sanctions screening vs. other business data 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?

The description adds useful context beyond annotations: it specifies the official service used (VIES/HMRC) and the return fields (validity, name, address). No contradictions with readOnlyHint and idempotentHint. It could mention error handling but is still 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 two sentences, concise and front-loaded. Every sentence earns its place: first explains the action, second explains the return. 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?

Given that an output schema exists, the description adequately summarizes return values. Parameters are fully described. Minor missing details (e.g., error handling, rate limits) but overall complete for a validation tool with good annotations.

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 has 100% description coverage, and the description adds a valuable example for vat_number (without country prefix). It also clarifies the country code format (UPPERCASE, GB for UK). This adds meaning beyond 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 clearly states the verb 'Validate', the resource 'VAT registration number', and the specific service (EU VIES or HMRC for GB). It also distinguishes itself from siblings like autocomplete_address and lookup_company, which do different things.

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 (to validate VAT numbers) but does not provide explicit guidance on when not to use or compare to siblings. No exclusions or alternatives are mentioned.

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