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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds real value on top by disclosing the full response composition (contract text with [Platzhalter], 30/360 schedule, legal notes, SKR03/SKR04 entries, generator link), that no key or cost is required, and the edit/sign/download workflow. Nothing contradicts readOnlyHint — generation is stateless output, not persistence — though error behavior and any limits are left unmentioned.

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 output description is front-loaded in the first sentence, followed by invocation rules and then access links, which is a sensible order. It is dense but not padded; the only redundancy is that the POST paragraph is repeated verbatim as the schema's top-level description.

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 45-parameter, deeply nested generator with no output schema, the description covers what comes back, how defaults and clearing work, and how the draft link round-trips — enough to call it correctly. Minor gaps remain: precedence when a flat and nested form are both supplied, and the default when scenario is omitted (the enum allows null without stating a fallback).

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 baseline is 3; the description exceeds it by explaining that nested and flat parameter names are equivalent, that missing fields and null preserve defaults while "" clears a field, and that draft accepts either a generator link or a prior draft object. That naming-equivalence and clearing semantics are not obvious from the 45-property schema and materially reduce invocation errors.

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 ('Erstellt einen Darlehensvertrag nach deutschem Recht') and enumerates the four covered scenarios (shareholder loan to GmbH/UG, company-to-shareholder, private incl. relatives, business-to-business), which effectively scopes it against siblings like schenkungsvertrag. It also lists what the response contains, so an agent knows both what it produces and which cases it covers 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?

The scenario enumeration implies when the tool applies, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative (e.g. schenkungsvertrag for gifts, notarkosten for notary costs). The agent must infer routing from the scenario names alone.

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