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?

Discloses key behaviors: executes real HTTP requests, authenticates with scoped API key, refuses /admin endpoints, and only permits declared HTTP methods. This adds context beyond annotations, though it could be more explicit about potential side effects given readOnlyHint=false.

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 concise sentences that efficiently convey purpose, prerequisites, and restrictions. No superfluous words, and key information 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?

For a dynamic meta-tool without output schema, the description covers major aspects: authentication, path/method constraints, and prerequisite tools. Could mention return format or error handling, but adequate for open-world 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?

With 100% schema description coverage, the description adds value by explaining path template substitution, method default, and how params are interpreted (placeholder substitution, query/body). This clarifies usage 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 identifies the tool as a 'Discovery meta-tool' that executes real HTTP requests against the Nordic Data API for non-admin endpoints, distinguishing it from sibling tools by referencing list_endpoints and get_endpoint_schema as prerequisites.

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 instructs to use list_endpoints and get_endpoint_schema first, and states that only non-admin endpoints and declared HTTP methods are permitted. While it does not list alternatives among curated tools, it provides clear guidance on when and how to use this 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?

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?

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds context about live OpenAPI source, inline $ref resolution, rejection of admin endpoints, and its role as a meta-tool. 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?

Four short, front-loaded sentences with zero fluff. Every sentence adds essential information: purpose, source, usage context, and restriction.

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 sufficiently explains what is returned (full param and response schema), how it's constructed (live OpenAPI, resolved $refs), and when to use it. Covers all necessary aspects for a retrieval 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 descriptions for both parameters. The description adds value by clarifying that concrete paths (e.g., '/api/company/dk/22756214') are accepted, beyond the placeholder paths from list_endpoints.

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 returns the full parameter and response schema for a single endpoint, sourced from the live OpenAPI spec with resolved $refs. It distinguishes itself from siblings like list_endpoints and call_endpoint.

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 advises using it after list_endpoints and before call_endpoint to learn required parameters. Also notes that admin endpoints are rejected, providing clear guidance on when not to use.

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 extensively discloses behavioral traits beyond annotations: cold/warm cache times, cache durations, partial response behavior with 'truncated' and 'sectionsUnavailable', paid registry costs and error codes (402), and disclaimer handling. Annotations only indicate idempotent and read-only; the description adds substantial operational 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 long but well-structured, front-loading the tool's purpose and usage context. Every section adds value, though it could be slightly more concise by grouping related details. Still, it earns its 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?

Given the tool's complexity and lack of output schema, the description thoroughly covers return sections, caching, partial results, error handling (402), disclaimer presentation, and next-step recommendations. No critical missing information for an AI agent to use the tool effectively.

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 two parameters. Description adds meaningful examples for id (e.g., 'DK CVR 8 digits, NO orgnr 9 digits') and clarifies country codes as ISO 3166-1 alpha-2 lowercase. This goes beyond the schema's JSON property descriptions.

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 a 'Full Know-Your-Business master report' for companies across 15 EU countries and lists 9 specific sections. It also provides context for consequential decisions, which distinguishes it from simpler lookup tools like lookup_company 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?

Explicitly states 'Run before a consequential decision — onboarding a counterparty, approving a payment, extending credit, or signing a contract.' It also advises not to retry on HTTP 402 for NL and DE. However, it does not explicitly name alternative tools or scenarios where alternatives are preferred.

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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds runtime behavior (reads OpenAPI spec, supports search filter, 230+ endpoints) 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 concise, front-loaded with purpose, and each sentence adds value. 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?

For a list tool with one optional parameter and strong annotations, the description covers purpose, usage, behavior, and limitations completely.

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 provides full parameter description with examples. The description adds context by stating the parameter is optional and reinforcing its filtering role.

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 a 'Discovery meta-tool' that lists all available API endpoints via the backend's live OpenAPI spec, distinguishing it from the curated sibling 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?

Explicitly describes when to use (discover capabilities beyond dedicated tools) and what to do next (use get_endpoint_schema and call_endpoint). Also notes admin endpoints are never returned.

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 and idempotentHint. The description adds critical context: reliance on official registries, country-specific behavior, paid registry interactions, error handling for 402. It does not contradict annotations. Minor omission: could mention data freshness or update frequency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with core use case and action. The description is detailed but organized (countries list, tier notes, error handling). Every sentence adds necessary information, though the country list could be more compact.

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?

Fully covers tool usage context: when to call, supported countries, quota differences, error handling, and what data is returned. With output schema present, doesn't need to detail every field. No gaps identified.

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 covers 100% of parameters with detailed descriptions (e.g., ID formats per country). The description adds value by explaining the overall use context and listing expected output fields, helping agents understand what parameters return.

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: 'look up basic company data' from official European registries, with a specific use case ('Call before onboarding a supplier or customer'). It distinguishes itself from siblings by focusing on company registration data, not LEIs or VAT validation.

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 tells when to use ('before onboarding a supplier or customer'), and when not to retry (HTTP 402 for free-tier NL/DE queries). Provides alternative action: surface the upgrade URL. Also details paid-tier quota costs for NL and DE.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by specifying the data source (OpenSanctions), list coverage, match scores with attribution, and the disclaimer about decision-support nature—none of which are in 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 somewhat lengthy but well-structured, starting with the primary use case. While some details (e.g., precise disclaimer presentation instructions) could be shortened, every sentence serves a purpose for proper tool usage.

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 indicated), the description adequately covers input context, behavioral notes, result interpretation (match scores, disclaimer), and user guidance. No gaps are evident for the tool's complexity level.

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%, covering all three parameters (names, fuzzy, min_score) adequately. The description does not add significant new information about parameter usage beyond what the schema provides, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool screens names against specific sanctions lists (UN, EU, OFAC, PEP) via OpenSanctions, with a specific verb and resource. It distinguishes from sibling tools like lookup_company or validate_vat, which serve different purposes.

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 says 'Call before onboarding a counterparty or processing a payment,' providing clear usage context. It implies this is the only tool for sanctions screening among siblings, but doesn't explicitly mention alternatives for different use cases.

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 declare readOnlyHint, idempotentHint, and destructiveHint false, which aligns with the description's 'validate' action. The description adds value by specifying the official services used (EU VIES, HMRC) and the return data (validity, name, address), but does not mention potential downtime or rate limits. No 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?

Two sentences: first provides usage context, second states action and outputs. No filler or redundancy. Highly efficient and front-loaded with key 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?

Given the tool's simplicity (two parameters, read-only validation), the description covers purpose, usage timing, service sources, and return fields. The presence of an output schema (not shown) reduces the need to detail return structure. Minor omission: no mention of error cases or service dependencies, but acceptable for a read-only tool with 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 coverage is 100% with detailed parameter descriptions for 'country' and 'vat_number'. The description reinforces the schema (e.g., 'Without country prefix') but does not add new semantic information beyond the schema. Hence, it meets the baseline for high coverage.

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: validating a VAT number against official EU and HMRC services. It also provides specific use cases (before invoice, payment, storing VAT), differentiating it from sibling tools which deal with company lookups, sanctions screening, or API endpoints.

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 instructs when to call the tool (before invoicing, cross-border payment, storing VAT number), giving clear context. However, it does not mention situations where this tool should not be used or suggest alternative tools, though the sibling set does not include another VAT validator.

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