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.