Företagskoll – Nordic & UK company data

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

Annotations cover read-only and open-world behavior, but the description adds real value beyond them: the $0.01 USDC-on-Base x402 cost and the 'not charged if the company isn't found' policy, which materially affects agent decisions. It still omits auth requirements and rate limits, so it falls short of a 5.

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

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

Information is front-loaded with the core action and country scope first, followed by returned fields, data source, and pricing. It is dense but every clause carries information; the trailing parenthetical and fragments are slightly compressed rather than wasteful.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (name, legal form, status, bankruptcy/liquidation, registration date, address, industry codes, plus employees/website/VAT where available). Combined with the pricing note, an agent has what it needs to call and interpret 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 description coverage is 100%, so both the 'id' formats and the 'country' enum are already fully documented in the schema. The description merely restates the country list, adding no syntax or format detail beyond the structured fields, which makes the baseline 3 correct.

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

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

States a specific verb (look up) plus resource (company by registry number) and enumerates the returned attributes and supported countries, so the agent knows exactly what it retrieves. It does not explicitly distinguish itself from get_company_financials or validate_company_id, leaving that differentiation implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'look up a company by registry number' and the country list, but there is no explicit when-to-use or when-not guidance and no mention of the sibling tools as alternatives (e.g., validate_company_id for checking an ID before paying, or get_company_financials when financials are needed).

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 and openWorldHint, and the description adds substantial context beyond them: the $0.05 USDC on Base x402 cost, the no-charge condition when no machine-readable accounts exist, and the UK balance-sheet-only filing caveat. These are important behavioral traits for a paid lookup tool, though rate limits and permissions are not covered.

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 what the tool returns, then moves to pricing and caveats. The long first sentence lists many metrics but each item is informative, and the following sentences earn their place by clarifying billing and UK filing limitations.

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?

No output schema exists, so the description carries return-value context and does list the key figures, plus pricing and caveats. It is nearly complete for calling the tool, but the omitted FI support and lack of sibling routing leave a notable 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?

Schema description coverage is 100%, so the baseline would be 3. The description's country list omits Finland/FI even though the schema country enum includes FI and the schema id description explicitly mentions Finnish Business ID (0112038-9). This omission makes the description's parameter guidance misleading rather than merely redundant.

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

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

States a specific resource and scope: key figures from a company's latest annual accounts, with an explicit list of returned metrics and supported countries. This clearly distinguishes it from the sibling tools get_company and validate_company_id, which do not return financial statement 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?

Provides useful context for when to use it: latest annual accounts in specific countries, plus pricing and a no-charge condition if no machine-readable accounts exist. However, it never names the sibling tools or explicitly states when to prefer this over get_company or validate_company_id, so it lacks alternative routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, non-networked read. The description adds genuinely new context beyond that: the operation is a pure format/checksum validation (not a registry lookup) and it is free, which is pricing information absent from annotations and schema. No auth or rate-limit detail, but the bar is lower here.

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 short sentences, zero filler, and the core behavior (format + check digit) is front-loaded before the cost note. Every word earns its place.

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

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

There is no output schema, so the description carries the burden of explaining what comes back; it implies a validity verdict but never says the result is a pass/fail with a reason per registry. Given full parameter coverage and annotations covering safety, this is the only meaningful 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?

Schema description coverage is 100%: the id property already lists the Swedish, Norwegian, Finnish and UK formats with examples, and country already enumerates codes with a default. The description adds the same country list but no new syntax, format, or edge-case meaning. Baseline 3 when the schema does the heavy lifting.

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 names a specific verb and resource ('Checks the format and check digit of a ... company number') and enumerates the four supported registries, which is far more precise than the title alone. It does not explicitly distinguish itself from get_company / get_company_financials, though validation versus retrieval is inherently distinct.

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 word 'Free' implies this is a cheap pre-flight check to run before paying for get_company, and that usage is inferable. However, there is no explicit statement of when to use this versus the sibling lookup tools, nor any when-not guidance.

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