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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses the error contract (raises with an object containing code, message, and hint), per-error recovery steps (bad_request fix-and-retry, upstream retry at most once after ~a minute), register-native relevance ordering with a confidence caveat, and zero-hit semantics (hits is [], total is 0, hint suggests dropping AS/LTD-type suffixes). No contradiction with the annotations.

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

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

Purpose is front-loaded and the text is organized into clear paragraphs: purpose and country mapping, workflow and result semantics, then error recovery. It is long (~250 words), and a phrase like 'the norway company lookup tool for the norwegian business registry' is mildly redundant, but nearly every other sentence carries distinct operational information.

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

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

With an output schema present and safety annotations covering side effects, the description covers the full call-and-interpret loop: search semantics, country mapping, thin-hit warning, ordering, empty results, naming conventions, and error recovery. Nothing an agent needs to invoke this tool correctly or act on its results is missing.

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%, so the baseline is 3; the description still adds registry-specific meaning beyond the schema — country="NO" maps to Brønnøysundregistrene/Enhetsregisteret and country="GB" to Companies House returning a company number (CRN). It also ties limit to the register's relevance order, helping the agent interpret result ranking rather than just validating input ranges.

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 first sentence states a specific verb and resource ('Search a national company register by name') with an explicit selection condition ('when you have a name rather than an identifier'). It clearly distinguishes itself from the sibling lookup_company, which is the tool to call once an identifier is known.

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 routes the agent: use search_company when the user gives a company name, then call lookup_company with the id of the right hit for the full report. It also names fallbacks (list_countries for unsupported_country) and warns that results are thin and must not be acted on directly, leaving no ambiguity about the search-to-report workflow.

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