Meistron

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

Beyond the annotations (readOnlyHint=false), the description adds meaningful behavioral context: it creates a draft that does not request money, is not booked, and sends nothing to the customer. It also states that conversion to invoice is not possible through this access. This clarifies the tool's side effects and limitations, though it does not cover all potential behaviors (e.g., error conditions).

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 short paragraphs, each serving a distinct purpose: core action, parameter behavior, and limitation. It is front-loaded with the primary action and uses bold for key terms. Every sentence adds value, with 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 6 optional parameters and no output schema, the description explains the core workflow (draft quote, copying from order, adding own items) and a key limitation (no conversion to invoice). It does not describe the return value, but without an output schema this is not strictly required. The description is sufficient for an agent to invoke the tool effectively in most scenarios.

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?

Although the schema covers all parameters (100%), the description enhances understanding by explaining how auftrag_id interacts with positionen (copies material and time, with options to exclude via ohne_zeiten/ohne_material). It also clarifies that positionen can be used alone or in addition, which is not fully explicit 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 opens with a specific verb and resource: 'Legt einen ANGEBOTS-Entwurf an' (creates a quote draft). It clearly distinguishes from invoices by stating it is not an invoice, requests no money, and is not booked, and explicitly says it sends nothing to the customer, differentiating from related tools like rechnung_anlegen.

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 provides useful context: it clarifies when to use this tool (for creating quote drafts) and when not (conversion to invoice is not possible here). It also explains the behavior when an order (auftrag_id) is supplied, implying a common usage scenario. However, it does not explicitly name alternative tools for invoicing, though the context strongly suggests rechnung_anlegen.

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, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond these by stating it shows which offers were already converted to invoices and which remain open, giving the agent a clear picture of the output without needing to infer.

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 sentences, front-loaded with the verb and resource, and every clause adds relevant information. No 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?

As there is no output schema, the description carries the responsibility of explaining return values. It lists the fields (Nummer, Kunde, Betrag, Status) and the special conversion status, which covers the core information. It doesn't mention limits or ordering, but those are optional parameters in the 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?

Since schema description coverage is 100%, the baseline is 3. The description aligns with the 'nur_offen' parameter by mentioning open offers, but doesn't detail parameter syntax or add meaning beyond the schema. It mentions output fields rather than input parameters.

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 the specific verb 'Listet' (lists) and identifies the resource 'Angebote' with key fields (Nummer, Kunde, Betrag, Status). It clearly distinguishes from sibling tools like angebot_anlegen (create) and rechnungen_suchen (invoices) by focusing on offers and their conversion state.

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 about what the tool returns (offers with conversion status), implying its use for checking which offers are converted or open. However, it does not explicitly name alternatives or state when not to use it, stopping short of full 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 idempotentHint=true, so the read-only safety profile is covered. The description adds behavioral context by explaining what happens when no time period is provided (shows next upcoming appointments) and which fields appear in the results, going 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?

Two concise, front-loaded sentences: the first states the primary purpose and output fields; the second explains the default behavior without a time period. 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 is sufficient for a read-only list tool with a fully documented schema and annotations. It explains the core action, returned fields, and the no-period fallback. It does not mention pagination or max limits, but those are already in the schema, so the description is complete enough for safe 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?

The input schema has 100% description coverage, and each parameter is documented (e.g., 'bis' = latest date, 'von' = earliest date, 'anzahl' = max count). The description adds the concept of a date range and the no-period default, but mostly relies on the schema to explain individual parameters.

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 the specific verb 'Listet' (lists) and resource 'Aufträge' (orders), clearly indicating that this tool searches within a date range. It distinguishes from sibling tools like 'auftrag_ansehen' (view a single order) and 'angebote_suchen' (search quotes) by focusing on listing orders and by naming the returned fields.

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 clearly implies use cases: searching orders over a period, and falling back to upcoming dates when no period is given. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough to guide selection among sibling 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?

Even though annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, the description adds crucial behavioral details: it only touches the specified fields ('Nur die angegebenen Felder werden angefasst') and confirms no status change or external sends. This goes beyond the annotations and helps an agent avoid unintended side effects. There is 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?

The description is two short sentences, front-loaded with the main action and field list, and follows with clear exclusions. Every word earns its place; there is no fluff or repetition of schema/annotation 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?

Considering the tool's moderate complexity (6 params, no output schema, no nested objects), the description covers what it changes, the partial-update behavior, and what it does not do. It omits details about return values or required permissions, but these are not critical for basic invocation. The annotations fill in the safety profile, making the description sufficient for an agent to use the tool 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?

Schema description coverage is 50%, so the description must compensate for ort, titel, and beschreibung which lack schema descriptions. The description clarifies that these fields are the updatable ones, and the phrase 'Nur die angegebenen Felder' communicates that unspecified parameters are ignored, which is essential parameter semantics. While it does not detail formats for the undocumented fields, the property names are intuitive, and the date parameters already have 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 explicitly states the action (Ändert) and the resource (bestehenden Auftrags), and lists the specific fields it modifies: Titel, Beschreibung, Ort oder Termin. It also differentiates from siblings by clarifying that it does not change status or send anything, which is important given tools like rechnung_versenden and auftrag_anlegen. This leaves no ambiguity about the tool's core purpose.

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 clearly indicates that this tool is for changing specific fields and explicitly states exclusions ('Ändert NICHT den Status und verschickt nichts'). This gives an agent context for when to use this update tool versus others that might handle status changes or sending, but it does not name alternative tools explicitly, so it falls short of a perfect score.

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 description reveals key behavioral traits beyond the annotations: default responsible person is the owner, notifications depend on a company setting defaulting to off, and the response always indicates what was actually sent. It also clarifies non-side-effects (no invoice, no customer write).

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 compact sentences, front-loaded with the core purpose, and every sentence contributes distinct value (fields, mandatory assignment, notification behavior, response meaning, exclusions). No redundant text.

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 create tool with no output schema and minimal annotations, the description covers essential defaults, side effects, and response semantics. It addresses potential ambiguities (who gets assigned, notification behavior) and explicitly states what it does not do.

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 documents all 7 parameters with descriptions (100% coverage). The tool description restates the field categories but does not add new parameter-level details; the default assignment for 'mitarbeiter' is also 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 starts with 'Legt einen neuen Auftrag an' — a specific verb and resource — and enumerates the fields (Titel, Beschreibung, Termin, Ort, Kunde). It explicitly distinguishes itself from invoice creation ('Legt KEINE Rechnung an'), which differentiates it from sibling rechnung_anlegen.

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 provides clear context for creating a new order, including required fields and default assignment. It explicitly excludes invoice creation and customer contact, but does not name alternative tools like auftrag_aendern or angebot_anlegen as options for other intents.

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 destructiveHint=false, and the description reinforces this with the term 'Zeigt'. It adds value beyond annotations by listing the exact fields returned, which is especially helpful since no output schema is present. No contradictions with annotations found.

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, concise sentence that immediately states the purpose and key content. Every word contributes meaning, with no redundancy or 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 simple view-detail tool with one parameter and no output schema, the description is sufficiently complete. It details what information will be shown and implies the need for an order ID. Minor omissions like prerequisites (e.g., the order must exist) are implicit and not critical.

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% because the only parameter 'auftrag_id' is described as 'Die Kennung des Auftrags.' The description does not add any additional detail about the parameter beyond what the schema already provides, so it meets the baseline but does not exceed it.

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 function: "Zeigt einen einzelnen Auftrag ausführlich" (shows a single order in detail), and enumerates the specific data displayed (description, date, location, customer, assigned employees, invoices). This distinguishes it from siblings like 'auftraege_suchen' (search orders) and 'auftrag_aendern' (change order).

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 defines a clear context: use when you need detailed information about a specific order, particularly given the singular focus and the requirement of an auftrag_id. However, it does not explicitly exclude alternatives or mention when not to use it, such as for searching across multiple orders.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by enumerating the specific metrics returned (counts, sums), which helps set expectations. It does not contradict annotations and provides value beyond the structured hints.

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 sentences long and efficiently front-loads the key metrics in the first sentence, with a usage recommendation in the second. Every word contributes to understanding, with no redundant fluff or repetition of schema details.

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, no-parameter overview tool, the description is quite complete: it lists all key figures and the intended use case. There is no output schema, so the description carries the burden of conveying return semantics, which it does adequately. A slight gap is that it does not specify output format (e.g., text vs structured object), but the enumerated metrics make it sufficient 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 input schema has no parameters (object with no properties), so there is nothing to explain. With zero parameters, the description's focus on outputs is appropriate. Schema coverage is trivially 100%, and the description confirms no input is needed, aligning with the tool's overview nature.

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: it provides current key figures (open/scheduled orders, unpaid/overdue invoices, total open items). This is a specific verb+resource combination that distinguishes it from sibling tools like auftraege_suchen or rechnungen_suchen, which focus on individual records rather than an aggregate overview.

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 says 'Guter erster Aufruf, um zu verstehen, worum es gerade geht' (good first call to understand what's going on), which serves as a clear usage guideline for when to invoke this tool. It does not mention exclusions or alternatives, but the context of being an overview tool is sufficient for agents to choose it appropriately among 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?

The description goes well beyond the annotations by disclosing that files are only stored, not processed, and that the human must later initiate import/posting. It also clarifies login requirements and the intentional absence of chat-based file transfer. These are critical behavioral traits that annotations alone do not capture.

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, front-loaded with the main purpose, and every sentence contributes a necessary operational detail (storage behavior, no chat transmission, login, follow-up). It is structured clearly into three short paragraphs without 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?

The tool has no output schema, but the description states that it returns a link, covers prerequisites (login), limitations (no processing), and downstream actions (check with datei_stand). It is complete enough for a human to use it correctly without further documentation.

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% with detailed per-parameter descriptions (e.g., 'lieferant_id' explains the conditional requirement and consequences). The narrative adds context like the list of purposes ('datanorm', 'dokument', etc.) but does not materially improve on the schema's own semantics. Baseline 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 begins with a specific verb+resource construct: 'Fordert eine Datei vom Menschen an und gibt einen Link zurück' (requests a file from the human and returns a link). It clearly distinguishes itself from sibling tools like datei_stand by focusing on the request action and its outbound link.

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 lists use cases ('Für Preisdateien von Lieferanten (DATANORM), PDFs, Belege und Fotos') and provides workflow guidance, including showing the link, login requirements, and following up with 'datei_stand'. It also states a clear alternative: do not send the file via chat, making it a well-scoped tool.

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, and non-destructive hints. The description goes beyond these by explaining the human processing delay and advising against frequent polling, which is important behavioral context not present in the structured metadata.

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 tightly written sentences: the first states the core purpose, the second provides usage timing and a critical warning. Every phrase earns its place, with no redundancy or fluff.

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?

Despite having no parameters and no output schema, the description fully covers the tool's purpose, when to use it, and a key behavioral caveat. It gives enough context for an agent to know what to expect and how to interact appropriately.

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 parameter-level explanation is unnecessary. The schema trivially covers all (non-existent) parameters, and the description provides no parameter details because none exist. Baseline 4 applies per guidelines for no-parameter tools.

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 shows which files were requested and which have arrived, using the specific verb 'Zeigt' and resource 'Dateien'. It also distinguishes itself from the sibling tool 'datei_anfordern' by positioning itself as the post-request check, making its purpose 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?

Explicitly instructs to use this tool after 'datei_anfordern' instead of guessing, and provides a clear exclusion: do not call repeatedly in short intervals because the human needs time. This gives strong when-to-use and when-not-to-use guidance, referencing the related workflow.

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 description adds rich behavioral context beyond annotations: it states that changes affect only future invoices/offers, not existing ones, and enumerates fields that cannot be changed even with approval. This goes well beyond the idempotentHint annotation and discloses important operational constraints.

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 well-structured and front-loaded with the core purpose. Each paragraph earns its place: effect scope, immutable fields, and required prerequisite. There is 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 settings-change tool with no output schema, the description covers purpose, scope of effects, exclusions, and a necessary precondition. It also handles edge cases like unsupported requests, making it complete enough for an agent to invoke 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?

Schema coverage is 100% and parameter descriptions are already detailed. The description adds value by providing example values for 'feld' (e.g., default_payment_terms) and pointing to 'einstellungen_ansehen' as the source of valid field names, which helps the agent select parameters correctly.

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: 'Ändert eine Firmen- oder Rechnungsvorgabe' (changes a company or invoice default). It clearly distinguishes from the sibling tool 'einstellungen_ansehen' by focusing on the modifying action and its scope.

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 instructs to call 'einstellungen_ansehen' first to know the current value, and it lists non-changeable fields, directing users to refer to Meistron for those. This gives clear when-to-use and when-not-to-use guidance, with an explicit alternative.

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, destructiveHint=false, and idempotentHint=true. The description adds value beyond annotations by specifying what is intentionally excluded from the view (Bankverbindung, Steuernummern, Nummernkreise), giving the agent a clearer picture of the tool's limitations. No contradiction with 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 two sentences long, front-loaded with the main purpose, followed by a practical use case and a concise list of exclusions. Every sentence adds meaningful information with no redundancy or fluff.

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 settings viewer, the description is complete: it explains what data is shown, what is intentionally omitted, and when it is useful. No output schema exists, but for this simple tool the description sufficiently conveys expected behavior.

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 accepts zero parameters, and the input schema is empty. The description adds no parameter-specific details, as none are needed. The baseline for 0 params is 4, and the description does not need to compensate for any 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 clearly states the tool shows company data and settings for invoices and offers, naming specific elements (Zahlungsziel, Steuersatz, Stundensatz, Textbausteine). It also explicitly lists what is NOT shown (bank details, tax numbers, number ranges), which distinguishes it from related tools like einstellungen_aendern.

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 provides a clear use case: 'Nützlich, um zu erklären, warum eine Rechnung aussieht, wie sie aussieht.' This implies when to use the tool, though it does not explicitly mention alternatives or exclusion cases. The sibling tool einstellungen_aendern is not referenced, but the name and description make the view-vs-edit distinction obvious.

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?

Die Beschreibung ergänzt die Annotationen sinnvoll, indem sie die Duplikatprüfung ('Prüft vorher, ob es einen gleichnamigen bereits gibt') und die Optionalität von Anschrift/Kontaktdaten offenlegt. Dies geht über die reinen Annotationen hinaus.

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?

Die Beschreibung besteht aus drei knappen Sätzen, die zuerst den Zweck nennen und dann die wichtigsten Verhaltensdetails. Keine überflüssigen Informationen.

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?

Für eine einfache Erstellungsaktion werden Zweck, Duplikatverhalten und optionale Felder abgedeckt. Da kein Output-Schema existiert, fehlen Angaben zu Rückgabewerten oder Fehlerverhalten, aber das ist für diesen einfachen Fall vertretbar.

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?

Die Schema-Beschreibungsabdeckung ist mit 40% gering. Die Beschreibung sagt, dass der Name genügt und Anschrift/Kontaktdaten optional sind, was etwas Bedeutung hinzufügt, aber nicht auf einzelne Parameter eingeht. Das Schema selbst markiert name als einziges Pflichtfeld, daher ist der Mehrwert begrenzt.

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?

Die Beschreibung 'Legt einen neuen Kunden an' verwendet ein spezifisches Verb und eine Ressource, die klar von anderen Anlegen-Tools (wie Angebot oder Auftrag) unterscheidet. Zusätzlich wird das Duplikatverhalten erwähnt, was den Zweck weiter präzisiert.

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?

Die Beschreibung gibt klaren Anwendungskontext: Erstellen eines Kunden, wobei nur der Name erforderlich ist. Sie nennt jedoch keine expliziten Alternativen oder Ausschlusskriterien, daher kein 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 cover read-only and non-destructive behavior. The description adds the limitation that this tool does not perform price import, which is valuable behavioral context. It also specifies the data returned (suppliers and last DATANORM price import).

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, front-loaded with the primary function, and the exclusion is stated succinctly. No 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 zero-parameter read-only tool, the description fully explains what it returns (suppliers and last price read dates) and what it doesn't do (import). No output schema needed given the simple 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 tool has no parameters, and the description correctly doesn't invent any. Baseline for zero parameters is 4, and there's nothing to deduct.

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 lists suppliers and their last price import dates, with a specific verb ('Nennt') and resource. It also explains the purpose (answering whether catalog prices are current), which differentiates it from import-related 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?

Explicitly states when NOT to use it (for price import) and directs to the alternative (uploading a file to Meistron). This provides clear usage boundaries and alternatives.

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, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds useful context about the data fields shown (e.g., price, stock, location, and where stock comes from), but it doesn't disclose error handling, not-found behavior, or authorization requirements, which are not covered by 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 a single, well-structured sentence that front-loads the action ('Zeigt') and resource ('Katalogartikel'), then lists the data scope. Every part contributes, with 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 simple read-only view tool with one parameter and strong annotations, the description covers the key output fields (price, stock, location, stock movements). Without an output schema, it could be more explicit about the structure or extent of movements, but the description is largely sufficient for the tool's complexity.

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 covers 100% of parameter descriptions: material_id is described as 'Die Kennung des Artikels.' The tool description adds no extra semantics beyond reinforcing that the tool views a catalog item by that identifier. Baseline 3 is appropriate given high schema coverage.

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 the specific verb 'Zeigt' (shows) and clearly identifies the resource as a catalog article, listing the key data fields (price, stock, location, and stock movements). This distinguishes it from sibling tools like material_suchen (search) and material_buchen (book), providing a clear purpose.

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 tool is for viewing a single material's details, but it doesn't provide explicit guidance on when to choose this over alternatives like material_suchen, nor does it mention prerequisites or exclusions. The usage context is only 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?

The description discloses a critical behavioral trait beyond the destructiveHint annotation: 'Jede Buchung wird dauerhaft protokolliert und lässt sich NICHT löschen — ein Fehler wird durch eine Gegenbuchung berichtigt'. This irreversibility and correction mechanism is not implied by the annotation alone and is essential for safe invocation. It also clarifies that Inventur expects the counted stock, not the difference, which is a non-obvious system behavior.

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, efficiently front-loaded with the main action and followed by essential caveats and alternative guidance. Every sentence earns its place with no redundancy or 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 mutation tool with no output schema, the description covers the core purpose, the three operational modes, the irreversibility, and the key alternative. Combined with the fully described schema, it provides enough context for an agent to decide and invoke 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?

Schema description coverage is 100%, so baseline is 3. The tool description repeats some parameter semantics (e.g., menge for Inventur) already present in the schema, but does not add meaning beyond it. It does provide a high-level context, but the schema already carries the full parameter explanations.

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 function: 'Bucht eine Bestandsbewegung auf einem Katalogartikel' with three specific movement types (Zugang, Abgang, Inventur). It also explicitly distinguishes this tool from the sibling 'material_zuweisen' for order-linked material, making the purpose 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?

Provides explicit when-to-use guidance by naming the alternative tool: 'Für Material, das auf einen Auftrag geht, ist „material_zuweisen" richtig'. This tells the agent exactly when not to use this tool and which sibling to prefer, alongside the three movement-type contexts.

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 the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context: it returns price, unit, and stock, and explains the `nur_knapp` filter behavior. No contradictions with 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 two sentences long, front-loads the core purpose, and adds a valuable use case in the second sentence. Every word earns its place; no fluff 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?

Given the tool's moderate complexity (4 optional params, no output schema), the description covers the main behavior, key filter, and return fields. It doesn't detail pagination, but the schema documents `anzahl`. The description is adequate and well-contextualized within its sibling set.

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 meaningful descriptions for all 4 parameters. The description's mention of `nur_knapp` reinforces the schema but doesn't add new semantic detail beyond it. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ('Durchsucht') and resource ('Materialkatalog'), and clearly states the search criteria (Bezeichnung/Artikelnummer) and output fields (Preis, Einheit, Lagerbestand). This distinguishes it from sibling tools like material_ansehen (view single) and material_buchen (booking), making the purpose 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 description gives a concrete usage scenario: with `nur_knapp` it lists items below minimum stock, described as 'der übliche Einstieg vor einer Bestellung' (the usual entry point before an order). While it doesn't explicitly name alternatives or exclusions, the context is clear enough for an agent to know when to choose this search tool.

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 annotations (destructiveHint=true), the description details immediate stock deduction, rejection on insufficient stock rather than negative booking, and explicitly states it does not create an invoice. These are concrete behavioral disclosures that go well 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, front-loaded with the primary action, and each sentence provides essential information (purpose, side effect, error behavior, non-behavior). No wasted words.

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 purpose, side effects, error handling, and a key non-effect. Since there is no output schema, a brief note on what the tool returns would strengthen completeness, but the current description is sufficiently informative for an agent to invoke it correctly in most contexts.

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 covers all parameters with descriptions (100% coverage), but the description adds semantic value by clarifying that material_id can refer to either a material or a tool ('Material oder Werkzeug'), and that the menge check relates to stock sufficiency. This is a non-trivial addition 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 clearly states the tool's function with a specific verb ('Bucht') and resource ('Material oder Werkzeug auf einen Auftrag'), and explicitly distinguishes it from invoice creation by noting 'Legt KEINE Rechnung an.' This differentiates it from sibling tools like rechnung_anlegen and material_buchen.

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 provides usage context by explaining that consumption is assigned to the order for later invoicing, and it excludes one alternative ('Legt KEINE Rechnung an'). It doesn't explicitly name alternatives, but the context is clear enough for an agent to infer when this tool is appropriate.

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, destructiveHint, idempotentHint, and openWorldHint. The description adds context about what is listed (people assignable to orders) and the output fields (name and ID), which is useful. However, no further behavioral traits (e.g., pagination) are disclosed, but given the simple nature and annotation coverage, this is adequate.

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 sentences: the first states the tool's function, the second provides usage guidance. It is concise and front-loaded.

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 listing tool with zero parameters and no output schema, the description covers the essential context: what it returns, when to use it, and the annotations cover safety. No additional information seems necessary.

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 takes no parameters. With zero parameters, the baseline is 4; the description doesn't need to compensate and does not add parameter-specific details.

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 the specific verb 'nennt' (lists), specifies the resource 'Personen, denen ein Auftrag zugewiesen werden kann' (people assignable to an order), and notes the output includes name and identifier. This clearly distinguishes it from sibling tools like 'lieferanten_auflisten'.

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 instruction 'Vor dem Anlegen eines Auftrags aufrufen, wenn nicht klar ist, wer zuständig sein soll' explicitly states when to use the tool (before creating an order when responsibility is unclear). This provides clear context and timing.

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 description discloses important behavioral details beyond the annotations: the draft remains editable, has no invoice number until sending, the number is assigned only at send time to keep the numbering sequence complete, and nothing is transmitted. It also explains how order data is incorporated, which is valuable context for a create 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?

The description is compact, front-loaded, and free of redundancy. The first paragraph covers the core draft semantics and the second the order-based workflow; every sentence contributes essential 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 tool with no output schema and six optional parameters, the description adequately explains the main workflow, the draft behavior, the fact that no sending occurs, and the order-integration path. A fully complete description might also mention what is returned on success or how required fields are handled, but the provided context is already strong.

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 describes all six parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantic context by explaining the relationship between auftrag_id and positionen, the usual adoption path, and the possibility of using own positions instead or additionally. This goes slightly beyond 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?

The description opens with 'Legt einen Rechnungs-ENTWURF an', a specific verb and resource that clearly identifies the tool's function. It further distinguishes itself from related tools by explicitly stating that the draft has no invoice number and that nothing is sent to the customer.

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 provides clear usage context: the common workflow is to pass an order so the draft adopts its material and time entries, while own positions can be added as an alternative. It does not name sibling alternatives explicitly, but the contrast with sending/running invoices is implied strongly 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 description adds behavioral context beyond the readOnlyHint and idempotentHint annotations by specifying exactly which data will be shown (amounts, tax, payment status, dunning level, associated order). While it does not cover error cases, the strong annotations reduce the burden, and this field list sets clear expectations for the return content.

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 front-loaded with the action and resource, and every word adds value. There is no redundant or extraneous 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 simple read-only tool with one parameter and no output schema, the description is sufficiently complete. It states the purpose and the specific fields returned, which compensates for the lack of an output schema. It does not mention error handling, but given the tool's simplicity and the strong annotations, that is not a critical 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?

Schema coverage is 100%: the only parameter rechnung_id is described as 'Die Kennung der Rechnung'. The description does not add any additional parameter semantics beyond what the schema already provides, so 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 uses the specific verb 'Zeigt' (shows) and clearly identifies the resource as 'eine einzelne Rechnung' (a single invoice), listing the key fields it returns (amounts, tax, payment status, dunning level, associated order). This distinguishes it from sibling tools like 'rechnung_anlegen' (create) and 'rechnungen_suchen' (search).

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 usage for viewing a single invoice by saying 'einzelne Rechnung', but it does not explicitly state when to use this tool over alternatives or mention exclusions. There is no reference to sibling tools or conditions that would make this tool the right choice.

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 read-only annotation, the description discloses meaningful behavioral traits: the output fields, the filtering semantics of 'nur_offen', and the sort order (oldest overdue first). This adds context beyond the structured annotations, but it does not cover every parameter (e.g., 'nur_ueberfaellig') or pagination behavior. Still, it goes beyond a minimal disclosure.

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 short sentences, front-loaded with the main action and output, and ends with a useful use-case tip. No superfluous words; every clause contributes either to purpose, filtering behavior, or usage context.

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 search tool with five optional parameters and no output schema, the description covers the essential output fields, the default list fields, and a common workflow. The schema handles the remaining parameters, and the context is sufficient for a typical invoice search use 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?

The schema already provides 100% parameter descriptions, so the baseline is 3. The description reinforces the meaning of 'nur_offen' but does not add new syntax, format details, or explain the remaining parameters beyond what the schema already offers. The added value is contextual ('usual entry point') rather than semantic.

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: 'Listet Rechnungen' (lists invoices), followed by the exact fields returned (number, customer, amount, status, due date). It clearly distinguishes this search tool from sibling tools like 'rechnung_ansehen' (view single invoice) and 'rechnung_anlegen' (create invoice).

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 provides practical usage guidance by explaining that using 'nur_offen' returns unpaid invoices sorted by age of overdue, and calls this 'the usual entry point for open items' (übliche Einstieg für offene Posten). It gives a clear when-to-use scenario, though it does not explicitly mention alternatives or when not to use the tool.

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 annotations (destructiveHint, non-idempotent), the description discloses concrete side effects: the invoice number is assigned, PDF frozen, and sending logged, making the invoice immutable per GoBD. It also details the preview behavior (nothing goes out without 'freigabe') and warns that email cannot be recalled, addressing the human-safety aspect.

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 longer than average but structured in digestible sections: a summary paragraph, a bold warning about letters, and a numbered two-step procedure. Every sentence carries essential safety or operational information, and no filler is present.

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 no output schema and a high-risk, irreversible operation, the description covers prerequisites (draft status, customer email), the exact sequence of calls, what is returned at each step (preview with Freigabewort), and all constraints (no custom recipient/subject/text). This is sufficient for an agent to invoke the tool safely.

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 descriptions (100% coverage), but the description adds workflow context for 'freigabe' (must come from the preview, never invented) and 'weg' (only email, no letters). It also clarifies what parameters are not available (recipient, subject, text) and where the email address comes from, multiplying the schema's usefulness.

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 'Versendet einen Rechnungs-Entwurf per E-Mail an den Kunden' (sends an invoice draft by email to the customer), clearly identifying the verb (send), resource (invoice draft), and channel (email). This distinct action is separated from sibling tools like rechnung_anlegen (create) or rechnung_ansehen (view), and the description explicitly notes that letters are NOT supported, further differentiating scope.

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 provides explicit when-to-use guidance: it explains that letters must not be sent via this tool and directs users to Meistron for that purpose. It also defines a strict two-step workflow (preview first, then explicit human approval with the Freigabewort) and states what parameters cannot be changed (recipient, subject, text).

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral nuance by noting that days with missing clock-out are also listed and do not count, which goes beyond structured metadata.

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 sentences: the first states the core purpose and output, the second adds an important caveat about missing clock-outs. No filler words, and the key information is front-loaded.

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 input (period), the output (per-employee sums, day counts, missing clock-out days), and a data quality note. It does not describe sort order or exact JSON structure, but given the absence of an output schema and the tool's simplicity, this is nearly complete.

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 'von' and 'bis' are fully described in the schema with date format descriptions. The tool description only references 'eines Zeitraums', confirming the period but adding no extra semantics. With 100% schema coverage, a 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 uses the specific verb 'Fasst zusammen' with the resource 'erfassten Arbeitszeiten eines Zeitraums' and details the output per employee. It clearly distinguishes from sibling tools like 'mitarbeiter_auflisten' by focusing on summarizing time records.

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 usage when a summary of working hours for a period is needed, giving clear context. It does not explicitly state exclusions or alternatives, but no direct sibling for this task exists among the listed tools, so the implied guidance is sufficient.

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