firma.de Rechner für Gründer

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, and no destructive effects. The description adds valuable context beyond that: it is an estimate, not tax advice, the 2027 calculation is based on a draft bill, and it is free without an API key. It could mention error handling or performance, but the added behavioral context is solid.

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 core purpose and is dense for a 20-parameter tool, which is justified. It does repeat the 2027 draft caveat (also present in the year parameter schema) and could be more skimmable with structure, but there is little pure filler.

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 complex tax calculator with no output schema, the description covers purpose, calculation scope, output components (Rechenweg, Durchschnitts-/Grenzsteuersatz, Vorauszahlungen, monthly savings recommendation, link), input format, years, legal disclaimer, and access model. 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 coverage is 100%, so the baseline is 3. The description adds meaningful usage detail: POST bodies can place fields flat or under a 'values' object, missing/null fields keep defaults, and input from a prior response can be passed unchanged. That goes beyond the per-parameter schema descriptions.

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 uses a specific verb ('Rechnet') and resource ('Einkommensteuer', 'Solidaritätszuschlag', 'Gewerbesteuer') and scopes it to 'Selbstständige und Gründer'. It names the exact calculation engine and enumerates the tax components, making the tool's function unmistakable.

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 clearly states the target audience (self-employed and founders), the supported years, and that the tool is free and keyless. However, it does not explicitly compare to siblings like gmbh_steuern or state when not to use it, leaving a small gap in 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=false, so safety and idempotency are covered; the description adds that no API key or cost is involved and that invalid values or unknown fields produce a 400 with per-field problems. It does not disclose limits, rate limiting, or what the generator 'Hinweise' contain, and it introduces a '?format=pdf' query option that has no counterpart in the schema's md/json/xml enum, which muddies the contract.

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?

Purpose and the two variants are front-loaded in the first sentence, and the second paragraph carries the operational rules. Some space is spent on promotional/testimonial material (KoSIT-Validator, Mustang, veraPDF, link to the human calculator) that helps trust but is not needed to invoke the tool.

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, yet the description explains what comes back — generator hints, totals, and the XML, plus the md/json/xml renderings — and notes that responses are in German. For a nested 11-parameter generator this is nearly complete; only the pdf format mismatch and missing limits leave a small gap.

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?

With 64% schema coverage over 11 parameters, the schema does most of the work, but the description adds the crucial merge semantics — missing fields and null keep defaults, "" explicitly clears a field — which the per-field schema text does not state. It also enumerates the top-level draft fields (seller, buyer, lines ≤50, number, issueDate, service, payment, taxCase, format, note, cashAccounting) so the agent knows the shape before opening the schema, though the ?format=pdf mention conflicts with the enum.

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 states a specific verb and resource — it turns a JSON draft into an E-Rechnung per EN 16931 — and immediately names the two concrete output flavors (XRechnung 3.0 for authorities with Leitweg-ID, ZUGFeRD 2.5.2 PDF/A-3 for companies). An agent can tell exactly what it gets and that none of the sibling calculators/contract tools does this.

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 a clear decision rule for the two output variants based on recipient type (Behörde vs. Unternehmen) and states the tool is free and needs no key, which is the main gating question for an agent. What is missing is any explicit statement of when not to use it (e.g., trivial amounts) or how it relates to the sibling tax/legal tools.

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/idempotent/non-destructive, and the description adds substantial context beyond that: the result is a calculation, not a recommendation; the Finanzamt only accepts an appropriate salary and an all-profit salary is a classic verdeckte Gewinnausschüttung; 2027 figures are based on unresolved draft legislation; and it is explicitly an unverbindliche Schätzung, not tax advice. It also discloses response language (German), format options, and that a link back into the calculator is returned.

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 core description is one enormous multi-clause German sentence that packs the entire tax mechanics (Körperschaftsteuer, Gewerbesteuer, Abgeltungsteuer, Günstigerprüfung, Teileinkünfteverfahren, Kirchensteuer) into an unscannable block. Much of that detail restates what the per-parameter schema already documents. Only the trailing POST/format paragraphs are cleanly structured and front-loaded information is 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?

For a 24-parameter, zero-required calculation tool with no output schema, the description covers what comes back (Rechenweg, Hinweise zum Fall, salary curve, calculator link), the year coverage and draft caveat, and the input conventions. An agent has enough to call it correctly; only the relationship to the sibling tax tools is left unaddressed.

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 each parameter already carries a detailed description plus x-only-when conditions, so the baseline is 3. The description still adds real value by explaining the POST body shape (flat fields or under values), that an earlier response's input object can be passed through unchanged, and that missing or null fields fall back to calculator defaults — behavior not evident from the property list 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?

The opening sentence names a specific verb and resource: it computes three questions in one pass for the Gesellschafter-Geschäftsführer of a GmbH/UG, using the same engine as the firma.de calculator. The three computed areas (Sozialversicherungsstatus, net private outcome, Angemessenheit) are enumerated concretely. It does not differentiate itself from siblings such as gmbh_steuern or einkommensteuer, which overlap thematically.

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 clear invocation guidance: POST with JSON, fields flat or nested under values, missing/null fields keep defaults, format also settable via ?format=md. It also states the tool is free and keyless. What is missing is when to choose this over the sibling tax tools — no exclusions or alternative routing are 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 a read-only, idempotent, non-destructive, closed-world call, and the description adds material context beyond them: free and keyless, German-language responses in markdown or JSON, retention of defaults for omitted/null fields, a link back into the human calculator, and the important caveat that 2027 income tax uses an undecided government draft. It also discloses the liability framing ('unverbindliche Schätzung, keine Steuerberatung'), which an agent needs when relaying results.

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?

Purpose, caveats and POST mechanics are front-loaded, which is good, but the long middle block enumerating Körperschaftsteuer rate schedules through 2032, § references and the list of response components does not help an agent decide or call. That informational mass dilutes the operational content an agent actually needs.

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 19-parameter, no-output-schema tool this covers what is needed: how to submit parameters, default/null behavior, output format choice, language, and the main caveat about 2027. The return payload is described in narrative form (Rechenweg, comparison, prepayments, checks, link), which compensates for the missing output schema. Only the explicit routing to alternative calculators 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 coverage is 100% so the baseline is 3, but the description adds real meaning for the request shape: the `values` wrapper versus flat GET-style fields, the passthrough of a prior `input` object, and the query-string alternative `?format=md` that the schema does not mention. The tax-law parameter semantics themselves (share thresholds, hebesatz minimums, recipient) are already carried by the schema descriptions.

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 concrete verb and resource: it computes the taxes on a GmbH/UG profit before tax and what remains for the shareholder, using the same engine as firma.de's calculator. The scope boundary ('Der Gewinn zählt nach dem Geschäftsführergehalt; das Gehalt selbst rechnet die API nicht') further separates it from the sibling geschaeftsfuehrergehalt and from einkommensteuer, which covers only personal income.

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 the input contract for both GET-style flat fields and POST with a `values` object, notes that missing fields and nulls keep calculator defaults, that `input` from a previous response can be reused unchanged, and that `format` / `?format=md` are available. It also implies a boundary (salary is not computed here), but never explicitly names a sibling calculator or a when-not-to-use condition.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: open access with no key, no data stored, benchmark substitution for omitted values, and the md-vs-json response mode. It does not describe latency or limits, but that is minor here.

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 structure is sensible: what it computes, how to feed it, what comes back, and reference links. The opening sentence is dense – a long enumeration of outputs – but each clause carries information an agent needs, and there is no filler. Slightly tighter front-loading would earn a 5.

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 27-parameter calculator with no output schema, the description covers what the result contains (financing gap, runway, monthly liquidity, cost drivers, scenarios), the output language and format, and the defaults behavior. Return-value detail is thin, but the enumerated output list compensates reasonably for 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 description coverage is 96%, so nearly every one of the 27 parameters is already documented in the schema, and the description does not restate or clarify individual parameter semantics. It only adds the framing that all fields are optional and default to industry values, plus the role of own cost items and hires. That is the baseline 3 for a schema-heavy tool.

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 names a concrete verb (rechnet aus) and a concrete resource (erstes Gründungsbudget), then enumerates the actual outputs it produces (Startfinanzierung, Lücke im Betrieb, tiefster Kontostand, Liquidität Monat für Monat, drei Szenarien). This makes it clearly distinguishable from sibling finance tools like cap_table or gmbh_steuern, which cover different artifacts.

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 explains the operating conditions well – every input is optional, missing values fall back to industry benchmarks, no key is required, and nothing is persisted – and it says the response comes in German as text or JSON. However, it never states when to choose this over a sibling tool or when a founding-budget calculation is not appropriate, so the when-to-use guidance remains implied.

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, idempotent, non-destructive, closed-world, so safety needs no restating. The description adds real value beyond them: the response anatomy (KV-Nummer or Norm, Rechenweg, payer, sums, conditional items, hints, deep link), German-language output, and the disclaimer that the result is an estimate since the binding calculation is the notary's under § 19 GNotKG.

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?

Purpose and case inventory are front-loaded, followed by the disclaimer, the POST contract, and the response format, which is logical. The case list is a single long enumeration and the POST paragraph repeats the schema's description verbatim, costing some density.

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 52-parameter, one-of-ten-case calculator with no output schema, the description supplies the missing piece: what a result contains and how conditional items are surfaced, plus the safety of the estimate framing. It does not explain pagination, error behavior for invalid case/field combinations, or size of the md output beyond 'kurz genug für den Chat'.

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 per-parameter semantics are already fully documented in the schema, and the POST paragraph here is nearly identical to the schema's own description field. The description does clarify that missing fields and nulls fall back to calculator defaults and that the flat/values nesting mirrors prior output, which is a mild addition over the schema rather than a substantive one.

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?

Specific verb plus resource set: 'Rechnet Notar- und Gerichtsgebühren nach dem GNotKG, die Grunderwerbsteuer je Bundesland und die Gebühren von Testaments- und Vorsorgeregister', then enumerates the ten supported cases. It is unambiguous what the tool computes, but it never names overlapping siblings (gruendungsbudget, gmbh_steuern, schenkungsvertrag) to steer selection.

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 operational context: free, no key, GET or POST, and explicitly how to re-submit a prior response ('case dazu, die Felder von input unverändert'). Missing an explicit statement of when to prefer this over the fee-adjacent sibling tools, 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description adds substantial context beyond them: the response contents (receipt text with [placeholders], amount in words, tax/net breakdown for businesses, generator warnings, a link that opens the receipt for signing and PDF/Word download), the German-language output, and the fact that no key or payment is required. It also discloses the null/empty-string semantics that govern mutation of a draft, which annotations cannot express.

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 long but front-loaded and organized into three functional blocks: what it produces, how to POST the payload, and what comes back plus where it lives. Every block earns its place for a 24-parameter tool, though a few clauses (repeating the case definitions already in the schema) could be trimmed without loss.

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 tool with 24 optional parameters and no output schema, the description carries the return-value burden well by naming the receipt text, amount in words, tax breakdown, warnings, and download link. The payload-shape and default/clearing rules cover the main invocation pitfalls. What is missing is error/blocked-state handling — the schema mentions a 'blocked' outcome for business sales over 250 € to business customers, but the description never explains what the agent receives in that case.

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 already high (83%), so the baseline is 3, but the description adds genuinely useful semantics the schema does not encode: that nested forms (payer.name, vat.rate) and the flat GET-style names are interchangeable, that missing fields and null leave the default in place while "" clears a field, and that draft accepts either a generator link or a prior response object. These are behavioral rules, not restatements of parameter descriptions.

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 opens with a specific verb and resource: 'Erstellt eine Quittung nach § 368 BGB', and enumerates the four receipt variants (privat, business, smallBusiness, invoicePayment) with their legal bases. An agent immediately knows this produces a German payment receipt, not an invoice or contract. Sibling differentiation is only implicit — 'Bestätigung einer Zahlung auf eine Rechnung' hints at the boundary with e_rechnung, but no sibling is named, so it falls short of a 5.

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 context is well established: which case value applies to which taxpayer situation, when vat is permitted ('Nur case=business, nicht bei Kaution, Darlehen oder Spende'), and an explicit negative case — 'donation: dafür gibt es keine Quittung, nur die amtliche Zuwendungsbestätigung'. There is no explicit routing away to sibling tools such as e_rechnung or darlehensvertrag, which keeps it at 4 rather than 5.

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 this as read-only, idempotent and non-destructive, and the description adds substantive behavior: the exact response contents (contract text with [Platzhalter], generator notes, per-donor tax check with Steuerklasse/Freibetrag/10-Jahres-Regel, filing deadline, draft link), the blocked outcome for property and shares, and the 400 personalData failure mode for GET with personal fields. Default handling for missing fields, null and empty string is also disclosed, which goes well 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?

Three dense paragraphs that are front-loaded with what is produced and what is out of scope, then the POST shape, then endpoints. Every sentence carries information given 76 parameters, though the first sentence is long and clause-heavy, and the draft-link mechanics are only fully explained 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?

For a 76-parameter, 0-required generation tool with no output schema, the description carries the necessary weight: it describes the response payload in detail, the alternatives (POST vs GET for personal data), and the blocked/error outcomes. Nothing an agent needs to call or interpret the tool correctly appears to be 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 87%, so per-parameter meanings are largely documented already, setting the baseline at 3. The description still adds non-obvious structural semantics the schema cannot express per-field: flat keys matching GET names or nesting under donors.donor1/donor2 (never a list), that missing/null preserves defaults while "" clears a text or date field, and that format and draft are accepted in the body.

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 gives a specific verb and resource ('Erstellt einen Schenkungsvertrag nach deutschem Recht') and immediately scopes it to fixed generator building blocks, naming the covered subjects (Geld, Fahrzeuge, bewegliche Gegenstände), the donor count, and what is explicitly excluded (Immobilien und GmbH-Anteile nur beim Notar). An agent can distinguish this from siblings like darlehensvertrag or quittung 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?

It states clear inclusion/exclusion rules: money and items may go to minors, vehicles only to adults, property and shares are notary-only and yield no contract text. It also states the tool is free and needs no key, and that personal data must be sent via POST. It stops short of explicitly naming sibling tools as alternatives, so routing is inferable rather than spelled out.

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