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

Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context beyond that by enumerating what the returned details include, particularly 'the latest event in the commercial register', which an agent cannot infer from the schema alone. It does not fully explain behavior when no company is found, but the annotations lower the bar.

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?

A single, information-dense sentence that front-loads what the tool returns and the accepted identifiers. No filler or redundant restatement of the title.

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 simple single-parameter lookup with strong read-only/idempotent annotations, the description covers the essential fields returned and the accepted inputs. It doesn't specify the exact response format, but no output schema exists and the scope is narrow enough that this is a minor 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 uid parameter already explains both Swiss UID formats and the Lundio slug alternative. The tool description merely repeats this information without adding new meaning, so the baseline of 3 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?

Description names a clear verb/resource pair: fetch details for one Swiss company. It also specifies the identifier forms (UID or Lundio slug) and the exact fields returned (seat, legal form, sector, purpose, latest event), which distinguishes it from siblings like get_company_network and search_companies.

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 clearly establishes that this tool is for retrieving a single company by an exact identifier, which implies it should not be used for discovery or listing (search_companies, list_new_companies). It stops short of explicitly stating 'use search_companies when you do not have a UID or slug', so it loses the top score.

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