Rechnungslotse: deutsche E-Rechnung

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

The readOnlyHint annotation covers the read-only safety profile, and the description adds meaningful behavioral context beyond it: it specifies what data will be returned (Anschrift, Steuernummer, Bankverbindung) and that the data source is the access-bound Betrieb, implying no external identifier is needed. No contradiction with annotations exists.

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 a single front-loaded sentence that names the action, the resource, the binding context, and the returned data categories. Every part contributes meaning and there is no redundant or filler content.

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 zero-parameter, read-only tool with no output schema, the description is reasonably complete: it explains what is read, whose data is read, and which fields are included. It does not describe the exact return format or error cases, but the simplicity of the tool makes this acceptable.

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 tool has zero parameters, so the baseline is 4. The description still clarifies the implicit input context: the relevant Betrieb is determined by the current access/Zugang, which prevents an agent from expecting a parameter for selecting the business.

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 verb plus resource: "Liest die Stammdaten des Betriebs" and enumerates the contained fields (address, tax number, bank details). It is clearly distinguishable from siblings like rechnung_lesen, which target invoices, and the various Prüf tools, which validate rather than retrieve master data.

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 use case is implied: call this tool when the current business's master data are needed, since it reads data for the Betrieb the access belongs to. However, no explicit when-to-use/when-not-to-use guidance or alternative tool comparison is provided, leaving some inference to the agent.

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?

With readOnlyHint=true, the safety profile is already provided by annotations. The description adds useful behavioral context by explaining the default list-all behavior when 'regel' is omitted, and by detailing what the explanation contains. There is no contradiction with the read-only annotation.

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 a single dense sentence with no filler. It front-loads the main action and examples, then lists the specific aspects of the explanation and the fallback behavior. Every clause contributes useful 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?

For a simple read-only tool with one optional parameter and no output schema, the description is complete. It tells the agent what the tool does, what kinds of rule IDs are valid, what the explanation covers, and what happens without an argument. No important selection or invocation information 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?

The schema already documents the single 'regel' parameter well, including case-insensitivity and an example. The description adds value by clarifying the behavior when the parameter is omitted, which is not expressed in the schema. This goes beyond the high schema coverage baseline.

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 verb and resource: it explains a rule ID from a validation message, with concrete examples like BR-08 and PEPPOL-EN16931-R053. The optional no-arg behavior is also covered, so the agent understands both modes of the tool. This clearly distinguishes it from all sibling 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?

The description gives a clear context for use: when the agent has a rule ID from a Prüfmeldung and needs a plain-language explanation. It also explains when no rule ID is given, the tool lists all explained rules. It does not explicitly name alternative tools or state when not to use it, but the usage context is unambiguous.

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?

The annotation readOnlyHint: true already indicates that the tool has no side effects. The description adds no additional behavioral information (e.g., error handling, authorization requirements, or rate limits), but it does not contradict the annotation. Since the annotation covers the primary safety aspect, a score of 3 is appropriate.

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 two concise sentences with no redundant information. It packs essential details—the legal basis, the exact thresholds, the time frame (2025 onwards), and the consequence of exceeding the limit—into a compact form. There is no fluff or unnecessary elaboration.

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?

Given that the tool is a simple check with two numeric inputs and no output schema, the description fully covers the necessary information. It states what the tool evaluates and what it returns (whether the regulation applies this and next year, and the immediate termination rule). An agent can confidently invoke this tool without needing additional context.

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?

Both parameters (umsatz_vorjahr and umsatz_laufendes_jahr) have descriptions in the schema, achieving 100% coverage. The tool description explains the significance of the turnover values but does not add extra guidance on parameter units, formats, or edge cases. With full schema coverage, the baseline of 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?

The description clearly states the tool's purpose: to check the two turnover limits of the small business regulation (§19 UStG) as amended from 2025. It specifies the exact thresholds (€25,000 previous year, €100,000 current year) and the output logic (whether the regulation still applies this and next year, and immediate loss of eligibility upon exceeding €100,000). This is a specific verb (prüft) plus a well-defined resource, and it is unique among the sibling 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?

The description implies when to use the tool (whenever a small business threshold check is needed) but does not explicitly mention when not to use it or name alternative tools. For example, it does not differentiate itself from generic 'pflicht_pruefen' or 'pflichtangaben_pruefen' tools, which could lead to ambiguity in a broader context. However, the high specificity mitigates this.

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 read-only nature is covered. The description adds valuable behavioral context: the address is a mandatory field under § 14 UStG and must not be produced from memory. This goes beyond the annotation and helps the agent use the tool correctly.

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 compact: two sentences that front-load the function and then provide the critical usage rule and legal rationale. No filler or 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?

For a simple read-only lookup tool with two well-documented parameters and no output schema, the description is complete. It covers the data source, return value, when to use it, and even the legal reason. An agent has enough information to invoke it 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 provides full descriptions for both parameters ('limit' and 'suche'), with coverage at 100%. The description does not add parameter-specific semantics beyond what the schema contains, so the baseline score 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 verb and resource: it searches the account's customer file ('Kundenkartei') and returns the full address. It also ties the tool to a concrete workflow ('VOR jedem rechnung_erstellen'), which clearly distinguishes it from siblings like 'rechnung_erstellen' and 'rechnungen_suchen'.

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 description gives explicit usage context: use it before creating an invoice if the recipient has already been supplied. It does not explicitly mention when not to use the tool or name alternative tools, but the condition is clear and actionable.

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 single readOnlyHint=false annotation, the description discloses key behavioral traits: aggregation of identical services, daily breakdown attachment, exclusivity (a service can never appear on two invoices), idempotency via vorgangsnummer, and monthly quota consumption. This is rich, useful context for a mutating operation.

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 dense sentences with no filler; each sentence adds distinct information: purpose, scoping default, aggregation behavior, exclusivity/idempotency, and quota. The core purpose is front-loaded in the first sentence.

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 7-parameter tool without an output schema, this definition is largely complete: it covers purpose, defaults, idempotency, aggregation, and quota. Minor gaps remain, such as the default period when both von and bis are omitted and the behavior if validation fails.

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 baseline is 3. The tool description adds real semantics on top: the default behavior when leistung_ids is omitted, the effect of verdichten on invoice positions and the attachment, and the role of vorgangsnummer as duplicate protection. It does not need to repeat the date formats already 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?

The first sentence clearly states the action: turning one customer's open services into a validated e-invoice (XRechnung, PDF, ZUGFeRD). This distinguishes it from tools like leistungen_offen or rechnung_erstellen, but it never explicitly names a sibling alternative.

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 description gives clear context: use it to bill one customer's open services, optionally scoped by leistung_ids or a date range, and notes the account requirement in the title. However, it does not say when to prefer a different tool or when not to use this one.

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?

The readOnlyHint annotation already indicates a read-only operation, and the description reinforces this with 'Zeigt' and 'Vorschau'. It also discloses that grouped sums match later invoices to the cent, which is useful behavioral information.

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 compact and focused, using three short sentences to convey purpose, use cases, and an important accuracy guarantee. There is no redundant or irrelevant 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?

For a simple read-only query with optional filters, the description provides enough context about output shape (individual items or per-customer sums) and accuracy. It does not mention defaults for omitted von/bis parameters or ordering, but this is minor given the tool's straightforward nature.

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 provides 100% parameter coverage with concise descriptions. The description restates the grouping semantics ('einzeln oder als Summe je Kunde') but does not add substantial extra detail beyond the schema, such as defaults or validation rules for the optional date range.

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 clearly states the tool's purpose: showing recorded but not yet invoiced services, either individually or aggregated per client. The title and description make it easy to distinguish from sibling tools like offene_posten or leistungen_abrechnen.

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 description explicitly gives use cases: checking what has not yet been invoiced in the current month and as a preview before monthly closing. It does not name sibling alternatives explicitly, but the intended scenarios are clear enough.

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?

The annotation only signals mutation (readOnlyHint=false), while the description adds that the Leistung remains open until billed, that article-derived price/tax values can be overridden by explicitly provided values, and that each call is reported back individually. The account prerequisite appears in the title but is not restated in the description.

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 short sentences carry the core action, the resulting status, the precedence rule, and the repeated-call behavior without filler. The most important information is front-loaded and every sentence earns 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 a write operation with no output schema, the description covers the operation's effect, the open status, price/tax resolution, and the no-batch behavior; parameters are fully documented in the schema. It could be slightly more explicit about the response shape, but the mention that each item is individually reported back gives a reasonable expectation.

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 documents all 10 parameters and the baseline is 3. The description adds valuable cross-parameter semantics: price and tax rate come from the article when given, and explicitly provided values take precedence. This is not stated in the schema and helps the agent decide between artikel, einzelpreis, and ust_prozent.

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 verb 'Schreibt' plus resource 'eine erbrachte Leistung auf einen Kunden' names the action precisely, and the categories (Stunden, Material, Pauschalen, Fahrtkosten) clarify scope. The phrase 'bleibt offen, bis sie abgerechnet wird' also distinguishes this recording tool from billing-oriented siblings like leistungen_abrechnen.

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 description gives clear context for when to record a Leistung and explicitly instructs repeated calls for multiple line items because there is no batch mode. It does not name a sibling alternative directly, but the 'offen bis abgerechnet' phrasing implies the later billing step.

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 declare readOnlyHint=true, and the description extends this by revealing the internal algorithm: it splits the ID into three parts, recalculates the MOD 97-10 checksum, and detects transposition errors. It does not describe the exact output shape or error behavior, but for a read-only validator the added context is substantial.

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 one compact, front-loaded sentence. Every clause adds operational meaning, and there is no redundant restating of the tool name or title.

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?

The tool is simple (one string parameter, read-only) and the description covers the core behavior fully. The only minor gap is that, with no output schema, it does not explicitly state the return format, but the verbs imply both the decomposed components and the validation result.

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 leitweg_id parameter is already fully documented with a type and example. The description adds no parameter-level details, so it sits at the baseline 3 and does not need to compensate for schema gaps.

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 specific operation (Zerlegt) on a specific resource (Leitweg-ID) and further specifies the exact validation logic (MOD 97-10, digit transpositions). This makes it clearly distinguishable from the sibling tools, which concern invoices, VAT, and customer searches.

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 intended use is implied: call this tool when a Leitweg-ID needs to be decomposed and checksum-validated. However, the description gives no explicit when-not-to-use guidance or comparison to siblings such as fehler_erklaeren or rechnung_pruefen, so usage guidance is only implicit.

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?

The readOnlyHint annotation already covers safety, and the description adds behavioral context: it returns days since due, open amount, and a computed dunning level that would be due according to business settings, implying no dunning action is actually triggered. The title also warns 'Konto nötig', which is useful auth context.

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?

Two sentences carry all necessary information: the first explains what is returned, the second states the intended use cases. No filler or repetition; both sentences earn their 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?

The tool is simple (one optional parameter, no output schema), and the description adequately covers the return content and purpose. With no output schema, it is valuable that the description names the key output fields, and the account requirement is disclosed in the title.

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 only parameter, limit, is fully documented in the schema with range and default. The description adds no additional parameter-specific meaning, but with 100% schema 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 verb ('Nennt') and resource ('die Rechnungen, deren Zahlungsziel abgelaufen ist'), and adds the exact criteria and returned fields. This clearly distinguishes it from siblings like rechnungen_suchen or rechnung_lesen, which are about searching or reading invoices generally, not specifically overdue ones with dunning levels.

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 description explicitly names two use cases: 'wer schuldet mir noch Geld?' and preparing a dunning run (Mahnlauf). It does not mention alternatives or when not to use this tool, but the context is clear enough for an agent to choose it for overdue-invoice scenarios.

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?

The readOnlyHint annotation already signals a read-only operation, and the description adds meaningful behavioral detail: it reports per required field whether it is present and takes Kleinbetragsrechnung, Kleinunternehmer, and Reverse Charge special cases into account. No contradiction with 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?

One dense sentence front-loads the core purpose and includes only operationally relevant details: input source flexibility, output granularity, and legal exceptions. There is no filler or 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?

For a tool with 11 parameters, nested objects, and no output schema, the description covers purpose, admissible input sources, result granularity, and key legal carve-outs. It does not specify the exact result container format or how to map raw Word/PDF content onto the structured parameters, but the schema and title provide enough for correct invocation.

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 73%, so the schema carries most of the parameter meaning. The description explains the legal purpose but does not elaborate on undocumented fields like iban, rechnungsnummer, or empfaenger; those names are reasonably self-explanatory, so this is acceptable but not exemplary.

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: 'Prüft die Angaben einer Rechnung gegen § 14 UStG'. It also differentiates the tool from generic invoice-checking siblings by explicitly covering Word/PDF invoices without a Datensatz and by naming the special-case rules (§ 33 UStDV, § 19, § 13b).

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 description gives clear usage context: validating invoice mandatory data against § 14 UStG, including invoices from Word/PDF without a dataset. It does not explicitly name alternative tools or state when not to use this tool, 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 readOnlyHint=true, and the description's 'Beantwortet' is consistent with a read-only query. The description adds a useful scoping constraint ('für einen konkreten deutschen Betrieb') and indicates the output includes a date and legal paragraph, but it does not disclose how inputs are combined, edge cases, or response structure beyond that.

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?

A single, efficient sentence that front-loads the verb and subject, states the scope, and names the concrete deliverable (date and paragraph). There is no redundant or filler content.

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?

The description covers the core purpose and output shape, and the schema covers all inputs. It lacks explicit handling of edge cases or a detailed explanation of how parameters affect the result, but for a read-only advisory tool with self-describing parameters this is adequate.

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 has 100% coverage with descriptions for all 5 parameters, so the parameters are already well-documented. The tool description adds no parameter-specific detail, but given the high schema coverage, no further explanation is needed.

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 ('Beantwortet') and a specific resource ('einen konkreten deutschen Betrieb'), and states exactly what question it answers: when e-invoices must be issued and what applies for receiving them, with date and legal paragraph references. This clearly distinguishes it from siblings like pflichtangaben_pruefen (invoice content) or kleinunternehmer_pruefen (small business status).

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 description implies the usage context (a German business needing its e-invoice obligation determined) but never explicitly says when to use this tool instead of alternatives. No exclusions or alternative routing are mentioned, so an agent must infer selection from the title and description 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?

Beyond the readOnlyHint annotation, the description discloses how each format is delivered: only xrechnung returns content inline, while PDFs are provided as links because Base64 would be impractical in a conversation. It also explains that zugferd is a PDF/A-3 with an embedded invoice dataset, setting clear expectations about file type and machine-readability.

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 moderately sized and front-loaded with the core action, followed by the critical format distinction. The WICHTIG warning and the Base64 rationale are justified despite the length. Slightly wordy, but every sentence contributes to correct usage.

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 bears the burden of explaining return behavior and does so: inline for xrechnung, links for PDFs. The title also signals the account requirement. It does not detail failure or not-found cases, but for a read-only fetch tool, the essential call-time knowledge is present.

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, so the baseline is 3. The description adds practical rationale for format selection and clarifies the real-world difference between zugferd and pdf, adding meaning beyond the enum labels. It does not add much for rechnung_id, but the schema already ties it to rechnung_erstellen.

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 'Holt eine Fassung einer erzeugten Rechnung', naming a specific verb, resource, and the fact that it works on already generated invoices. The detailed format breakdown further differentiates it from reading invoice metadata or searching, though it does not explicitly name a sibling tool.

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 description gives explicit format-selection rules: choose zugferd for a 'saubere E-Rechnung als PDF'/PDF/A, pdf only when no e-invoice is wanted, and xrechnung for authorities/validation. It also notes that xrechnung returns inline content while PDFs come as links, which informs the choice. It does not compare against sibling tools like rechnung_lesen, but the format context is strong.

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?

The readOnlyHint annotation is consistent with the read-only wording, and the description adds valuable behavioral context: results are scoped to the connected business and each row includes the open amount and overdue flag. Since there is no output schema, this output-oriented detail is especially useful.

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?

Two sentences convey the tool's purpose, filter axes, output fields, and two concrete use cases without redundancy. The most important information is front-loaded, and every sentence earns 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 a search/list tool with no required parameters and a readOnly annotation, the description covers scope, filter dimensions, and key output fields. The missing output schema is compensated by the explicit note that each row carries the open amount and overdue flag.

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 schema already documents all five parameters in detail. The description adds a useful conceptual grouping (status, time range, search term) and a practical example, but it does not provide material parameter-level 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?

The description starts with a specific verb ('Listet') and a clear resource ('Rechnungen des verbundenen Betriebs') and immediately names the filter dimensions: status, time range, and search term. This makes the plural list/search intent unmistakable and distinguishes it from sibling tools like rechnung_lesen or offene_posten.

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 example questions ('welche Rechnungen sind noch offen?', 'was habe ich der Müller GmbH im Juli berechnet?') clearly illustrate when to use this tool. It does not explicitly mention when not to use it or contrast it with 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?

Beyond the readOnlyHint=false annotation, the description discloses highly relevant behavioral traits: the invoice is validated, standard invoice attributes come from the connected Betrieb, repeated calls with the same bestellnummer do not create duplicates, and the call consumes monthly quota. This is exactly the kind of side-effect and idempotency context an agent needs before invoking a write tool.

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 sentences carry the full behavioral contract without repeating schema information. The primary action is front-loaded, and each sentence adds a distinct, valuable fact: what is created, what is auto-derived, and the idempotency/quota constraints.

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 mutating tool with nested schema objects but no output schema, the description covers the essential operational context: validation, formats, auto-derived fields, idempotency, and quota. It does not describe the return value or how to access the created invoice afterward, which is a minor gap but not critical for correct invocation.

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?

Even though schema field descriptions already cover bestellnummer and recipient details, the description adds semantic context not in the schema: sender, invoice number, and payment terms are supplied by the Betrieb rather than the caller, and bestellnummer acts as the idempotency key. With 67% schema coverage and rich nested parameter descriptions, the small additional parameter-level context is sufficient.

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 action and resource ('Erzeugt eine geprüfte E-Rechnung') with explicit formats (XRechnung, PDF, ZUGFeRD), making the tool's purpose unmistakable. It is clearly distinguished from sibling read/search/validate tools (rechnung_lesen, rechnung_pruefen, rechnungen_suchen) by the create verb and invoice-generation context.

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 description implies when to use the tool—whenever a validated E-Rechnung must be created—and conveys key operating conditions such as derived sender data, idempotency, and tariff quota. However, it does not explicitly state when not to use it or name an alternative sibling (e.g., use rechnung_datei to retrieve the file, or pflicht_pruefen to validate beforehand), so usage guidance remains implied rather than explicit.

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?

The annotation readOnlyHint is consistent with the description's claim of not saving the file. The description also specifies that it returns structured data, providing full transparency about the read-only behavior without any side effects.

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 a single, well-structured sentence that is concise and to the point. It avoids unnecessary details while covering the main functionality and output, making it easy for an agent to parse.

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?

Given the tool's moderate complexity (three optional parameters) and lack of an output schema, the description is complete. It lists the key return fields, which is essential for the agent to understand what data will be provided, and it clarifies the file type handling (XRechnung vs. ZUGFeRD-PDF).

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 input schema provides 100% coverage with descriptive comments for each parameter, including the mutual exclusivity of xml and datei_base64. However, the tool description itself does not add further meaning to the parameters beyond what the schema already provides, so the baseline score of 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?

The description clearly states the action (reads) and the resource (XRechnung or ZUGFeRD-PDF), and lists the specific data returned (sender, recipient, positions, amounts, due date, bank details). It distinguishes itself from sibling tools that create, check, or search invoices.

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 description explains what the tool does but does not explicitly name alternative tools or conditions for choosing this one. It mentions 'ohne die Datei zu speichern' which hints at a read-only operation, but it lacks direct guidance on when to prefer this over rechnung_pruefen or rechnung_erstellen.

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 provide readOnlyHint=true, and the description goes further by stating a meaningful data-handling guarantee: 'Die Datei wird nicht gespeichert; sie existiert nur für die Dauer der Prüfung.' It also discloses the output shape ('jeden Verstoß mit Regel-ID und Klartext') and directs users to an explanation page, adding behavioral context beyond the structured 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?

The description is three sentences with no filler: purpose, output, privacy behavior, and an external reference link. The most important information is front-loaded, and every sentence earns 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 a read-only validation tool with a fully documented schema and relevant annotations, the description is complete enough: it states what is checked, what the output looks like, that the file is not stored, and where to find rule explanations. The only minor omission is an explicit statement about the result when the invoice is fully valid, but that is reasonably inferable from 'liefert jeden Verstoß'.

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 input schema already covers all three parameters with 100% description coverage, so the baseline is 3. The tool description adds little about how to populate 'xml' versus 'datei_base64' beyond mentioning XRechnung and ZUGFeRD-PDF, but it does not meaningfully enhance the parameter-level guidance.

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 specific verb ('Prüft'), defines the resource ('XRechnung oder ein ZUGFeRD-PDF'), and specifies the exact standard ('EN 16931 + KoSIT-Regeln'). It also differentiates itself from sibling tools by emphasizing the 'vollständigen Normprüfer' and 'jeden Verstoß', making clear this is the comprehensive compliance checker, not a targeted check like Leitweg or Pflichtangaben.

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 phrase 'vollständigen Normprüfer (EN 16931 + KoSIT-Regeln)' communicates that this tool is for full normative validation of e-invoices, which gives clear context for when an agent should choose it over narrow sibling checkers. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a perfect 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?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: the Soll/Ist calculation mode depends on the stored business status, and the result contains no input tax and no prior corrections. This gives the agent a realistic picture of what to expect without overstating the tool's capabilities.

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, each earning its place: the first states the core calculation, the second explains the calculation basis, and the third clarifies exclusions and limitations. The title also adds a key prerequisite ('Konto nötig'). 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?

For a read-only calculation tool with two simple parameters and no output schema, the description covers the essential context: input period, data source, calculation basis, output contents (net/tax amounts with ELSTER keys), and exclusions. There is no missing information that would prevent an agent from invoking it 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 both parameters (von/bis with JJJJ-MM-TT format) at 100% coverage. The description only adds general context about a 'Zeitraum' without enriching the meaning of the individual parameters further. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 specifies a clear action ('Rechnet... zusammen') with a defined resource ('Ausgangsrechnungen'), input period, and output substance (Netto-/Steuerbeträge je Steuersatz, ELSTER-Kennziffern). It also explicitly distinguishes itself from a 'fertige Voranmeldung', so an agent can understand what the tool does and what it does not do.

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 description gives clear context: it is for a time period, based on outgoing invoices only, and uses ELSTER keys. It also explicitly excludes input tax and prior-month corrections, which helps the agent avoid using it for those cases. It does not name alternative tools, but no sibling appears to cover the same calculation, so the lack of explicit alternatives is a minor gap.

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 readOnlyHint=false annotation, the description discloses concrete behavioral outcomes: amount and date defaults, full payment marks the invoice paid, and overpayment is rejected in favor of a credit note. This gives the agent a clear picture of the mutation's side effects.

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 focused sentences with no filler; the core action, defaults, and edge case are front-loaded in a logical order. Every sentence earns 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?

The description plus fully covered schema is nearly sufficient for a correct call. It lacks an explicit mention of the account prerequisite (present only in the title) and does not describe the success/error response, leaving minor uncertainty for an agent.

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 all four parameters at 100% coverage, so the baseline is 3. The description adds value by clarifying betrag behavior beyond the schema (full coverage marks paid, overpayment rejected), but it mostly restates defaults already present 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?

The description names a specific verb and resource ('Verbucht einen Geldeingang auf eine Rechnung') and is clearly distinct from siblings like rechnung_erstellen or rechnungen_suchen. The scope is unambiguous.

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 context for use is clear: record an incoming payment against an invoice, with defaults and edge behavior stated. It explicitly excludes overpayments and directs the user to create a credit note instead, though it does not name an alternative tool and says little about when not to use it beyond that case.

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