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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the live-register source, the distinguishability of an empty matches list versus an unavailable flag, the 100-result cap with matchesTruncated, and the fact that names are non-unique. That is meaningful disclosure, though it stops short of describing latency/auth characteristics of a live federal register call, so a 3 rather than a 4.

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 front-loaded: the purpose and the search_companies precondition come first, then matching rules, then return semantics, then the truncation caveat. Every sentence carries distinct information, though the long run-on middle sentence about return fields could be tightened.

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?

An output schema exists, so return values need not be explained, yet the description usefully clarifies the tricky semantics an agent would otherwise misread: empty matches versus the unavailable flag, and the truncation cap. Combined with explicit matching constraints and the calling sequence, nothing needed to invoke this correctly 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%, and the schema already documents the 3-character minimum, prefix/exact matching, the "*" wildcard, and the canton code. The description largely restates these ('matches the start of the name', 'optional canton narrows it') with no syntax or formatting detail the schema lacks. Baseline 3 is the correct call.

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+resource ('resolves a company name to its UID') and explicitly scopes it as a live external lookup against Zefix rather than the local dataset. It names the sibling it depends on (search_companies) and the sibling it feeds (load_company), so an agent can place it precisely among the ten siblings.

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?

Gives an explicit precondition ('call search_companies first; use this only once that comes back empty') plus the reason an empty local page is not proof of nonexistence. It also prescribes the downstream step (disambiguate, then call load_company with the right UID), covering when, when-not, and what comes next.

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