Danish Company Info by SelskabsInfo

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

Goes well beyond the readOnly/openWorld annotations by disclosing the cost (1 credit), revealing that this call performs the base company lookup internally, and warning that employee figures come from a register interval that can lag reality by months. The data-freshness caveat and cost/overlap semantics are exactly the kind of context annotations cannot carry.

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 the output contents, then cost, then the sibling comparison — a sensible ordering. It is dense and somewhat run-on in the middle (employee counts, intervals, FTEs, tegningsregel in one clause), so it is efficient rather than elegant.

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 return-value burden and discharges it by naming every returned field group, plus cost, freshness caveat, and when to prefer get_company. An agent has everything needed to call it and to anticipate the response.

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% (the single cvr param is already documented with pattern and format), so the baseline would be 3. The description adds real value on top by specifying how to obtain the identifier — CVR lookup only, route to search_companies when you merely have a name — which is not in the schema.

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?

Opens with a specific plain-language statement of the operation — what one Danish company does and how big it is — then enumerates the exact fields returned (industry code, secondary industries, employee interval, FTEs, capital, tegningsregel, purpose). It is clearly distinct from siblings like get_contact_details, get_ownership, or get_company.

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 explicit routing for the two obvious forks: use search_companies first when you only have a name, and call get_company instead when the user wants more than this slice, since it costs the same. That is when-to-use, when-not, and the named alternative all in one place.

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 only declare readOnly/openWorld/non-destructive; the description adds substantial operational context beyond them — oldest-first ordering, truncation to the most recent 20 with an explicit notice, a 2-credit cost model, and a no-cost tier_restricted refusal with remediation guidance.

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?

Content is front-loaded: what the section contains comes first, then ordering/truncation, then cost and alternatives, then error handling. It is on the long side for a single-parameter read tool, but nearly every clause carries actionable information rather than repetition.

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 no output schema, the description must convey return characteristics, and it does: ordering, truncation behavior, and the substantive fields (events with subscription rate and implied valuation). Exact item structure isn't spelled out, a minor gap for a simple read 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 coverage is 100% and the single cvr parameter is fully documented with a pattern, so baseline is 3. The description adds modest value by framing the lookup as CVR-keyed and pointing to search_companies as the way to obtain a CVR when only a name is available.

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 (capital events of one Danish company) and enumerates what it contains: formation, increases and reductions, subscription rate and implied valuation. This clearly separates it from siblings like get_capital_overview and get_company without requiring the schema to be opened.

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 explicit routing rules: use search_companies first when only a name is known, and use one get_company call with `sections` when the profile or multiple sections are needed. It also covers the refusal path (tier_restricted) and tells the caller to report the limitation rather than imply missing data.

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?

Beyond the readOnly and non-destructive annotations, the description discloses plan requirements, credit cost, currency handling, estimation caveats, the meaning of kursOplyst=false, that ownership changes have no public purchase price, ordering, and truncation to the most recent 20 rounds. These are valuable behavioral details not present in the annotations or schema.

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 text is front-loaded with the core purpose and contains no filler, but it is a dense single paragraph with many semicolon-separated clauses. It is appropriately comprehensive for a complex due diligence tool, though it could be easier to scan if structured.

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 full burden of explaining returned content. It covers the main outputs, estimation caveats, currency behavior, ownership-change limitations, history truncation, and access requirements, making it complete enough to call correctly.

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?

The schema already fully documents the single cvr parameter with an 8-digit pattern, and the description adds no further parameter-specific syntax or constraints. With 100% schema description coverage, the baseline of 3 is appropriate.

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 states a specific resource (capital history of one Danish company) and enumerates exactly what is returned: formation, capital increases, reductions, ownership changes, cap tables and statistics. It also differentiates from the sibling get_capital_events, which is positioned as the lower-plan alternative for registered capital changes alone.

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?

It gives explicit usage context: requires Pro plan or higher and costs 3 credits, and on a lower plan the agent should use get_capital_events instead. This names the alternative and the condition that selects it, leaving little to inference.

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 only declare the read-only, non-destructive, open-world profile; the description adds the behavioral facts that actually matter — per-section credit cost, added latency, silent skipping of unentitled sections surfaced under 'warnings', and the contractual prerequisite for realOwners. That last point in particular prevents an agent from promising confidential UBO data to a merely paid user.

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 the core sentence, then a scannable bullet list, closing with the most operationally important caveat about warnings. It is long, but the per-section prose is load-bearing for section selection and not duplicated in the schema.

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 no output schema, the description carries the return-value burden and does so: it names the base fields and the contents of each optional section, plus the warnings channel. The one unaddressed area is the relationship to the extensive sibling set, which matters given how many of them overlap.

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?

The schema already documents both parameters at 100% coverage, but the description goes well beyond the enum names: it explains what each section contains (banded ownership percentages, SI-score meaning and its 'not a credit rating' caveat, courtData covering 8 authorities plus Statstidende), which materially changes whether an agent selects a section.

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 — 'Get full details for one Danish company by CVR number' — and enumerates exactly what the base response returns versus what the optional sections add. It never names the many section-specific siblings (get_financials, get_management, get_court_cases), so an agent cannot tell from this text alone when this composite tool is preferable to a narrow one.

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?

Explicit cost/latency guidance ('each one costs an extra API credit and adds latency', 'request only when the user asks about legal or regulatory history') tells the agent when to expand sections. It also explains plan-gating behavior and what to report to the user. The gap is the absence of any routing statement versus the sibling tools that fetch the same sections individually.

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 cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds real behavior: the cost is 1 credit and it is described as the cheapest call, and it explains the ophoert/ophoersDato trap for closed sole proprietorships. It stops short of error or rate-limit behavior, so it is strong rather than exhaustive.

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?

It is longer than typical but front-loads the return contents, then the interpretation caveat, then the routing and cost. Nearly every sentence carries decision-relevant information; the closing cost/get_company sentences are dense but not redundant.

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 no output schema, the description must describe return values and does: name entries and status entries with from/to dates, founding date, company form, plus the ophoert/ophoersDato fields. Nothing an agent needs to call it or read the result 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 there is a single CVR parameter, so baseline is 3. The description still adds meaning: the lookup key is the CVR, CVR survives a rename so old and current names are the same legal entity, and it redirects to search_companies when only a name is known.

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 precise verb-and-resource: every name and every status a Danish company has carried, with date ranges, founding date and company form. It explicitly distinguishes itself from the sibling get_company ('returns the whole profile') and names the CVR key, so an agent can route without opening a 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?

Gives concrete when-to-use rules: use search_companies first when you only have a name, and use get_company instead when the user wants more than name/status history. It also warns which field answers the 'is it closed' question ('ophoert', not 'status' alone), which is guidance an agent cannot infer elsewhere.

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?

Beyond the readOnly annotation, the description discloses the credit cost, the marketing-protection flag and its legal implication, and that empty fields are filled from the provider's own contact data where the plan covers it. These are meaningful behavioral traits an agent needs.

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 the returned fields, then adds usage and legal caveats. It is dense but every sentence carries useful information; minor tightening could improve flow.

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?

Because there is no output schema, the description appropriately explains what is returned, including the registered dates and the reklamebeskyttet flag. It also covers cost and sibling alternatives, making it complete for this 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?

There is a single required parameter and schema coverage is 100%, so the schema fully documents the CVR number format. The description reinforces lookup by CVR but adds no format or validation detail beyond the schema.

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 states a specific resource (phone, email, website and registered address for one Danish company) and its scope (one company, looked up by CVR). It distinguishes itself from siblings such as get_company explicitly.

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?

It gives explicit when-to-use alternatives: use search_companies first when only a name is known, and use get_company instead when the user wants more than contact details. Cost equivalence with get_company is also stated.

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 the safe read profile, and the description layers on what they cannot: the cost (2 credits), the expected result size ('Large'), and the exact failure mode — a tier_restricted refusal at no cost that must be reported to the user rather than as absent data. That last point is genuinely non-obvious agent guidance.

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 the resource scope before the cost and alternatives, and every sentence carries actionable content. It runs five dense clauses in a single block, so cost, size and the section-bundling advice compete for attention, but nothing is padding.

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 no output schema, the description still conveys enough to call correctly: source coverage, expected volume, cost, and failure behavior. Return shape (case identifiers, dates, court names) is left implicit, which is a minor gap for a data-retrieval tool with no schema to fall back on.

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?

Only one parameter and the schema already documents the 8-digit CVR pattern, so the schema does the heavy lifting. The description still adds routing value by telling the caller how to obtain the CVR when only a company name is known, which is meaning beyond the schema.

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 (civil court cases, decisions, orders, recalls, notices from 8 Danish authorities plus the Statstidende gazette) for exactly one Danish company, including matching under earlier names. That scope cleanly separates it from every sibling in the list, which cover financials, ownership, management and profile.

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 inclusion rule ('call it only when the user asks about legal or regulatory history'), a prerequisite path ('use search_companies first when you only have a name'), and a named cheaper alternative ('one get_company call with `sections`'). Both when-to-use and when-not-to-use are covered with the sibling tool named.

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 mark it read-only and non-destructive, but the description adds real behavioral context beyond them: a 2-credit cost, the tier-restriction refusal path with the exact error code, the zero-cost nature of that refusal, and the score's nature as an algorithmic rating. These are exactly the operational details annotations cannot carry.

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?

Three sentences, front-loaded with what the value is, then cost and alternatives, then the failure mode. Every sentence carries distinct decision-relevant information with no waste.

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 single-parameter read tool with no output schema, the description covers what is returned (score plus underlying warnings/flags), what it costs, when to prefer an alternative, and how a restricted plan manifests. Nothing needed to invoke it 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 sole parameter is already documented as an 8-digit CVR, so the schema does the heavy lifting. The description adds a useful lookup hint tying the parameter to the name-to-CVR workflow via search_companies, giving marginal meaning beyond the schema.

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 precise verb+resource: returns the SI-score (0-10) risk rating for one Danish company, including the warnings and critical flags behind it. It explicitly scopes the entity types (limited companies and foundations) and clarifies this is an algorithmic score, not a credit rating — a distinction an agent could otherwise get wrong when compared to get_company or get_financials.

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 the routing rule (use search_companies first when you only have a name) and an explicit alternative with its selection condition: one get_company call with `sections` is cheaper and faster when the user also needs the profile or multiple sections. It also tells the agent how to handle the tier_restricted outcome rather than reporting data as absent.

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 cover read-only/safe, but the description adds substantive behavior: ordering is publication order, not fiscal-year order, with late/corrected filings able to precede newer years; each year carries regnskabsaar, auditors and a revisorbistand/revideret flag; the call costs 2 credits; and out-of-plan calls are refused at no cost with tier_restricted. That goes well beyond the annotation 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?

Front-loaded with the resource and its fields, then progressively adds ordering caveat, cost, and alternatives. Dense but nearly every clause carries operational value; the first sentence is long and could be split, and the auditor-flag explanation is slightly verbose relative to its weight.

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 has to explain the return shape — and it does: up to four filed years, fields per year, fiscal-year keying, publication ordering, and per-year auditor metadata. Combined with cost and refusal semantics, nothing an agent needs to call and interpret 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 single cvr parameter is fully documented with a pattern, so the baseline is 3. The description adds usable context the schema cannot: the lookup key's role and the fallback path (search_companies when only a name is known).

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?

Opens with a specific verb+resource ('Annual accounts for one Danish company') and enumerates the returning fields (revenue, EBIT, EBITDA, profit, equity, balance sheet, key ratios). It also implicitly separates itself from siblings by naming get_company's `sections` and search_companies, so an agent can place it in the tool family without reading other definitions.

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 explicit routing: use search_companies first when you only have a name, and use one get_company call with `sections` when the user needs the profile or multiple sections. It also states what to do on a tier_restricted refusal (tell the user rather than reporting data absent), which is real decision guidance, not just context.

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 readOnly/openWorld/non-destructive, and the description adds genuinely non-obvious behavior: a 2-credit cost model and a no-cost tier_restricted refusal path with user-facing messaging guidance. It does not cover response shape or pagination, though for a single-entity section lookup that is a minor gap.

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-loads the covered entity types before cost and routing advice, so the most important information comes first. It is dense with parenthetical asides (the audit-firm clarification, the association note) and slightly longer than needed, but almost every clause carries real 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 no output schema, the description enumerates what the section returns (board, directors, founders, auditors, liquidator, association representatives) and flags edge cases like associations having no registered board. Cost behavior and the tier-restriction failure mode are also covered, leaving nothing an agent needs before calling.

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 `cvr` parameter is fully documented with its 8-digit pattern, so the schema does the heavy lifting. The description adds only indirect guidance (fall back to search_companies if you lack the CVR number, implying string identity input) — useful context but not syntax beyond the schema.

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 (directors, board, founders, auditors, liquidator, representatives of one Danish company via CVR) and delineates it from siblings, e.g. explicitly noting get_financials names the signing auditor. An agent can distinguish it from get_company or get_financials without opening a 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?

Gives explicit routing rules: use search_companies first when only a name is known; use get_company with `sections` when the profile or multiple sections are needed, since that is cheaper and faster. It also tells the agent how to interpret and report a tier_restricted refusal rather than treating it as missing data.

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?

Goes well past the annotations (which only declare a safe open-world read) by disclosing that percentages are register bands rather than exact values, that the call costs 2 credits, and that a plan limitation returns tier_restricted at no cost with an instruction not to report the data as absent. That last point is exactly the kind of failure-mode guidance an agent needs.

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?

What the tool returns and its semantic caveat come first, then lookup mechanics, then cost and alternatives, then error handling. Dense but every sentence carries actionable information; nothing is padding.

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 single-parameter read with no output schema, the description covers return semantics, pricing, alternative tooling, prerequisite resolution, and the tier_restricted failure path. An agent could invoke and handle this call correctly with no other information.

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 single parameter is fully described, so the schema carries the format burden (8-digit pattern). The description still adds meaning by implying the value must be a resolved CVR and routing name-only callers to search_companies.

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 ('Legal owners of one Danish company from the ownership register') and pins the identifier (CVR). It does not, however, distinguish itself from the closely-named siblings get_real_owners and get_ultimate_owners, which an agent could easily confuse with this one.

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?

Explicitly gives the prerequisite ('use search_companies first when you only have a name'), names an alternative path ('one get_company call with `sections` is cheaper and faster when the profile or multiple sections are needed'), and states the cost trade-off. The when-to-use and when-not-to-use conditions are both covered.

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?

Adds context beyond the annotations: a hard cap of 100 company relations, a plan-gating requirement (Starter or higher), and an explanation that legal-owner holdings surface as a "LEGAL EJER" role with an ejerandel band. Annotations already cover the read-only/non-destructive profile, so this is solid supplemental disclosure; only return shape/pagination remains unstated.

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-loads the verb and resource, then layers in provenance, domain semantics, limits, and access requirements. Every sentence carries information, though the register-role sentence is dense and the plan requirement could be trimmed or merged.

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 single-parameter read tool with no output schema, the description covers what is returned, the result cap, access tier, and a non-obvious data-representation quirk. Nothing an agent needs in order to call it 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 description coverage is 100%, so the id parameter is already fully documented with its pattern. The description repeats the enhedsnummer/search_persons provenance but adds no format or edge-case detail beyond the schema, making the baseline 3 appropriate.

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 ("Get one person by unit number") plus the scope of what comes back (companies they own, direct, or board membership). This is clearly distinguishable from search_persons (which finds people) and get_company / get_management (which are company-centric).

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?

Explicitly says where the id comes from (search_persons) and gives a use case: "Use this to map a person's business network." No when-not or explicit alternative is offered, so it stops short of full routing guidance.

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?

Beyond the readOnly/openWorld annotations, the description discloses the access contract (signed contract, not just a paid plan), the exact failure codes contract_required and tier_restricted, the fact that refusals are free, and the credit cost of 2. No hint of contradiction with the read-only 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?

Dense but front-loaded: identity and confidentiality come first, then cost, then the cheaper sibling pattern, then failure handling. Every sentence carries operational content, though the credit/pricing and refusal sentences could be tightened into one.

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 single-parameter read tool with no output schema, it covers access prerequisites, cost, error codes, and multi-section alternatives well. It does not describe what a UBO record actually contains (names, ownership shares, dates), which would help an agent set expectations, but nothing needed to call it 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% (a single patterned 8-digit CVR field), so the schema already carries the mechanics. The description still adds value by naming the CVR number as the lookup key and pointing to search_companies as the way to obtain one from a name.

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?

Names a specific resource with its Danish term and scope: 'Beneficial owners (reelle ejere, UBO) of one Danish company.' That makes the lookup unambiguous. It does not, however, distinguish itself from the closely related siblings get_ownership and get_ultimate_owners, so an agent must infer the boundary.

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?

It gives concrete routing rules: use search_companies first when you only have a name, and use one get_company call with `sections` when the user needs multiple sections. It also tells the agent how to behave on failure (report tier_restricted rather than claiming the data is absent), which is exactly the when/when-not guidance an agent needs.

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 this as a safe read operation, but the description adds important behavior beyond them: it costs 2 credits, tier-restricted plans are refused at no cost with tier_restricted naming the unlocking plan, and the caller should relay that rather than report absent data.

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 immediately covers lookup prerequisites, cost, cheaper alternatives, and refusal behavior. Every sentence adds actionable information with no wasted text.

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 single-parameter read tool with no output schema and annotations that already cover safety, the description supplies the remaining important context: cost, alternative tool routing, and tier-restriction handling. Nothing essential for correct invocation 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 description coverage is 100% and the single CVR parameter is already well documented with its 8-digit pattern. The description adds useful lookup semantics by stating that the tool is looked up by CVR number and that search_companies should be used first when only a name is known.

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 states a specific resource and result: companies owned by one Danish company, including the ownership band for each. It distinguishes itself from siblings by naming search_companies for name-only lookups and get_company for multi-section needs.

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?

It gives explicit when-to-use guidance: look up by CVR, use search_companies first when only a name is available, and use get_company with `sections` when the caller needs the profile or multiple sections. These alternatives and conditions are stated directly.

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, so the description adds substantial extra context: credit cost model (3 + 2 per holding company), depth and 12-company caps, the 'uafklaret' unresolved bucket, truncation at '_truncated', foundation and sole-proprietorship edge cases, and plan-gated refusal. This is far beyond what the annotations convey.

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?

It is dense and long, with some run-on clauses, but the purpose is front-loaded and nearly every sentence carries operational information (cost, limits, edge cases). Minor trimming of overlapping limit statements would improve it.

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 thoroughly by describing the return structure: per-person routes, ownership bands per link, director status flags, and the 'uafklaret' and '_truncated' keys. Nothing material for correct invocation or interpretation 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 schema documents both parameters; the description still adds meaning by explaining that max_depth controls chain expansion, that the default of 3 covers nearly every Danish group, and that deeper traversal costs credits per holding company. That links the parameter to cost and limits, not just shape.

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 precise verb and resource ('Follows the legal ownership chain... until it reaches people') and names what the output contains, distinguishing it from siblings like get_ownership and get_real_owners. An agent can tell what this tool uniquely delivers without opening the 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?

Explicitly says to use search_companies first when only a name is known, that the Pro plan or higher is required, and that this uses the public ownership register rather than the confidential beneficial-owner register. Those conditions effectively route the agent away from the sibling that covers real owners.

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?

Adds substantial context beyond the read-only annotations: the two output fields and their critical difference, why 'momsregistreret' is never false (joint registrations under another SE number), the 'forbehold' caveat, plan/credit cost, and error-not-guess semantics on register failure.

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 the core purpose, and every sentence carries operational value (field semantics, caveat, cost, error handling). It is dense and some clauses are long, but little is wasted.

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 no output schema, the description correctly takes on explaining the return fields and their interpretation. Combined with cost, source, and failure-mode guidance, an agent has everything needed to call and interpret it.

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 single parameter is fully documented there, so baseline 3 applies. The description restates that the checked VAT number is DK plus the CVR number, adding only marginal clarification over the schema.

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: checks whether DK + CVR is a valid, active VAT number and returns the register's name/address. It also explicitly distinguishes itself from every sibling by noting the VAT data comes from a different source than the other tools.

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?

Explains the situation (verifying a counterparty's VAT status, comparing against the CVR name) and gives strong when-not guidance: don't declare a company non-registered on an invalid number, treat errors as 'unknown' and retry. It doesn't name a specific alternative tool, but the source distinction from siblings supplies the routing context.

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?

Goes well beyond the readOnly/openWorld annotations: it discloses the deduplication rule (one row per bankruptcy, newest notice wins), the ingestion latency (two days after printing, usually within a week, so the past week is still filling in), coverage boundaries (complete only from January 2026), null cvr rows, and the credit cost per page. These are exactly the operational facts an agent needs before trusting the result.

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?

Dense but waste-free: identity first, then filters, dedup, coverage limits, latency, the Statistics Denmark reconciliation, output shape, and cost. Every sentence carries an operational fact and the caveats are front-loaded rather than buried.

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 eight optional parameters, no output schema, and rich annotations, the description covers what is missing elsewhere: freshness, completeness horizon, dedup semantics, null handling, and cost. Nothing an agent needs to call or interpret this tool is absent.

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% and the schema itself already documents each filter, including spelling pitfalls for city and industry. The description reinforces 'total' as the match count and explains the cvr/virksomhedsform shape, but adds little parameter-level detail the schema does not already carry, so the baseline 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?

Opens with a specific verb and resource ('Bankruptcy decrees ... for Danish companies') and immediately scopes it against the sibling tools by noting that get_company and the section tools consume the returned cvr. An agent can distinguish this from search_companies or list_new_companies without opening a 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?

States explicitly that no CVR number is needed, lists the filter axes (decree date, court, industry, city, name), and excludes personal bankruptcies and sole proprietorships. It also warns not to use it for pre-2026 counts and explains why its monthly totals differ from Statistics Denmark's.

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 readOnly/non-destructive/openWorld, and the description layers on real operational context: nightly CVR sync, active-only filtering, newest-first ordering, credit cost per page, availability on every plan, and that 'kommunekode' can be null while 'postnummer' is the reliable location field. These are exactly the traits an agent cannot infer from the schema or 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?

Front-loaded with the resource definition, then filters, then count semantics, then field caveats, then the sibling hand-off. Almost every clause carries new information. It is a dense single paragraph rather than a scannable structure, which slightly hurts retrieval of individual facts like the credit cost.

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 no output schema and nine optional parameters, the description compensates by naming the returned fields (city, postal code, industry, industry code, municipality code, company form), explaining 'total' as the full match count, and flagging the nullable field. An agent has everything needed to call it and interpret the result without further exploration.

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, but the description adds useful disambiguation: industry can be given as text or a 6-digit code, and 'virksomhedsform' takes the full name (Anpartsselskab) while 'virksomhedstype' is CVR's short code (APS) — a distinction that is easy to get wrong. It does not restate the date or paging parameters, which the schema already covers well.

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 with scope baked in: newly registered Danish companies, active, founded within 24 months, newest first, sourced nightly from CVR. It clearly tells an agent this answers 'which companies were founded' without a CVR number. It stops short of naming the obvious sibling (search_companies), so the boundary between the two list-style tools is left 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?

Gives concrete when-to-use guidance ('which companies were founded' filtered by date, industry, city, form or name) and explicit when-not-to-use routing: 'No street address, contact details or accounts here: call get_contact_details or get_financials with a row's cvr.' It also pre-empts a paging mistake by saying a count takes one call via 'total'. The only gap is no explicit contrast with search_companies.

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, openWorldHint=true, and destructiveHint=false, but the description adds useful behavioral detail: it lists the returned identity fields and explains that an 8-digit query is an exact CVR lookup yielding at most one result. It does not mention auth or rate limits, but it goes meaningfully beyond 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?

Four sentences, front-loaded with purpose, scope, alternative, and usage priority. Every sentence carries useful information with no noticeable waste.

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, but the description enumerates the identity and registration fields returned and explains the CVR exact-match behavior. Combined with the full schema coverage for pagination and query, it is complete for an agent to call this tool correctly.

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 schema already defines the parameters well; baseline is 3. The description adds meaning by clarifying that an 8-digit query triggers exact CVR lookup with at most one result, which is not obvious from the schema alone.

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 ('Search Danish companies'), the search key ('by name or CVR number'), and the returned data scope. It explicitly distinguishes itself from get_company by saying it returns identity and registration details only.

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 explicit routing guidance: 'call get_company for financials, ownership or risk data' and 'Use this first when the user names a company but gives no CVR number.' It also explains exact CVR lookup behavior, leaving little ambiguity about when to choose this tool.

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, openWorldHint and destructiveHint=false, so the safety profile is covered; the description adds genuinely useful context beyond them — the plan gating ('Needs the Starter plan or higher') and the fact that matches are candidates, not confirmed identities. It doesn't discuss rate limits or match ranking, which would push it higher.

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?

Three short sentences, all load-bearing: purpose first, return value and downstream dependency second, disambiguation caveat third. No filler or redundancy.

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 no output schema, the description steps in to describe the return ('candidate matches with the unit number') and the practical caveat about shared Danish names. It omits what other fields each candidate carries and whether results are ranked or ordered, which an agent would want for interpreting output.

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%, including the minLength and max-50/no-paging constraint on limit, so the schema carries parameter meaning. The description only echoes 'by name' without clarifying accepted query formats (partial vs full name, ordering), so it adds nothing beyond the structured fields — baseline 3.

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 ('Search people registered in Danish companies by name') and implicitly contrasts with search_companies (companies) and get_person (detail lookup, which it names as the downstream call). An agent can tell exactly what this returns and how it differs from the sibling get_person.

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 clear workflow context: use this to get the enhedsnummer that get_person requires, and disambiguate hits by checking associated companies. It does not explicitly say when to prefer search_companies or what to do if no matches come back, so it falls short of a full when/when-not/alternatives statement.

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