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

Annotations already declare readOnlyHint, idempotent, openWorldHint=false and non-destructive, so the safety profile is covered without the text. The description adds genuinely useful context: it is free and requires no API key, each share carries a 1 € nominal value, and the answer can be Markdown or JSON. It stops short of stating determinism, rounding behaviour, or limits, and its claim that it 'Antwortet auf Deutsch' sits awkwardly against the schema's default lang='en'.

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 key capability is front-loaded in one dense sentence, which is good, but the remainder mixes German and English, repeats the calculator link twice (human URL plus REST URL, the human link also appearing in the format parameter), and carries boilerplate ('Calculate a cap table', 'Each share has a nominal value of 1 €' partly duplicated by the schema). Roughly a third of the text is not earning its place.

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 an 11-parameter computational tool with nested objects and no output schema, the description covers the important missing pieces: the domain semantics of loans/pool/exit, the free-and-keyless access model, the nominal value convention, and the output format choice. The only real gap is that it does not characterise what the returned numbers look like beyond 'md or json', which is partly unavoidable given the absent output schema.

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 82%, so the baseline is 3; the description earns above that by explaining the domain model behind the parameters — convertible loans with cap, discount, floor and interest; a VSOP pool top-up; capital increase with Agio; and an optional exit waterfall with liquidation preference. This tells an agent what the nested objects are for, not just what they are named, though the same text contradicts the lang default of 'en'.

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 opening sentence names a specific resource and domain: a GmbH/UG cap table after a financing round, enumerating the computed outputs (price per share, before/after percentages, convertible loans, pool top-up, exit waterfall). 'Calculate a cap table' reinforces the verb. It is clearly distinguishable from the sibling tools (tax, notary costs, receipts), though the clarity is diluted by trailing URL and language boilerplate.

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?

Usage is only implied by the subject matter — an agent infers it should call this whenever a cap table or price-per-share calculation is needed. There is no explicit 'use this when…' or 'do not use for…', no statement of prerequisites beyond 'Free, no key', and no named alternatives among the siblings.

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