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

Goes well past the readOnly/openWorld annotations: it discloses the two-credit cost model, the tier_restricted refusal behavior (no charge, message names the upgrading plan, and a warning not to report the data as absent), and the precision ceiling of the returned percentages. That tier-refusal warning is exactly the kind of failure-mode context an agent cannot infer from structured fields.

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 purpose and scope, and every sentence carries actionable information (routing, cost, tier failure). It is a dense unbroken block though — cost and error-handling guidance are run together with the purpose statement, which slightly hurts scannability for an agent parsing quickly.

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 describing the return shape (banded percentages rather than exact figures, owner type, company owner CVR). With one well-documented parameter and read-only annotations, nothing an agent needs to call this correctly or interpret the response 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 sole parameter is fully documented in-schema, so the baseline would be 3. The description adds real routing value by saying the lookup key is the CVR number and that search_companies should be used first when only a name is available, which the schema does not say.

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 and resource (direct legal owners of one Danish company from the public ownership register) and pins down the exact return granularity — ownership/voting bands like "25-33%", person-vs-company flag, and company owner's CVR. It explicitly distinguishes itself from the two nearest siblings, get_ultimate_owners and get_real_owners, so an agent can disambiguate without opening any schema.

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?

Names both alternatives and the condition that selects each ('to follow holding companies to the people at the end, use get_ultimate_owners; for the confidential beneficial-owner register (UBO), get_real_owners'). Also gives the prerequisite path for name-only queries (search_companies first) and a cost-based routing rule to get_company with `sections` when multiple sections are needed.

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