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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is partly covered, but the description adds a genuinely new behavioral trait: a confirmation-before-write workflow where nothing changes without bestaetigt=true. It does not describe side effects such as notifications or what a successful response contains beyond the schema note.

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 tight fragments, with the most important constraint ('SCHREIBT IN DIE AKTE') front-loaded ahead of the action and the confirmation requirement. No waste, though the telegraphic style leaves intent slightly implicit.

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?

No output schema exists, but the description plus the bestaetigt schema note convey the key non-obvious behavior (the confirmation round-trip and the returned question). For a 6-parameter write tool it is largely complete, with the only gap being the undocumented fall/titel/detail parameters.

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 only 50%: quelle, faellig and bestaetigt are documented but fall, titel and detail are not. The description adds no parameter-level meaning beyond what the schema already provides, so at this borderline coverage it neither compensates nor over-explains.

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 clear verb+resource+scope: 'Aufgabe in einem Fall anlegen' (create a task within a case), reinforced by 'SCHREIBT IN DIE AKTE'. It does not differentiate from the sibling aufgabe_setzen, which appears to touch the same resource area, so it falls short of the top mark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit gating condition: only invoke with bestaetigt=true after asking the user. This is clear usage context. However, it offers no comparison or exclusion against the sibling aufgabe_setzen, so it is not a full when/when-not/alternative treatment.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable context beyond that: it is a write to the case file and requires a user-confirmation gate via bestaetigt=true. It does not detail permissions or side effects beyond the confirmation workflow.

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 short sentences, front-loaded with the critical write warning. Every sentence carries distinct information: write scope, action semantics, and the confirmation requirement. 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 write tool with no output schema, the description covers the essential behavioral contract: it writes to the case file, what it updates, and the confirmation requirement. Annotations cover safety. Minor gap is that 'fall' remains unexplained, but overall an agent has enough 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?

Schema description coverage is only 33%, so the description must compensate. It does: it explains that erledigt toggles done/open, that faellig and detail are optional changes, and that bestaetigt gates the whole operation. Only 'fall' lacks any semantic explanation in either description or 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?

States a specific verb and resource: set a task as done or open, optionally changing due date or detail. The write intent is front-loaded with 'SCHREIBT IN DIE AKTE.' It implicitly distinguishes itself from the sibling 'aufgabe_anlegen' by updating an existing task, though it does not name that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear precondition for invocation: only with bestaetigt=true after asking the user. However, it does not explain when to choose this tool over alternatives like aufgabe_anlegen or frist_setzen, nor does it state exclusions. Usage is implied rather than explicitly routed.

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 that this is a write operation (readOnlyHint=false) and non-destructive. The description adds the uppercase warning 'SCHREIBT IN DIE AKTE', the next-free-identifier assignment, and the user-confirmation requirement. It does not detail persistence or permission requirements beyond that, but the added confirmation workflow is meaningful.

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 short sentences, front-loaded with a strong warning, with no wasted words. Every sentence adds distinct information: side effect, purpose, identifier behavior, and confirmation condition.

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?

Complete enough for a one-parameter mutation tool: purpose, side effect, identifier behavior, and confirmation workflow are stated. Only the return value or response shape is left unspecified, which is minor since no output schema exists.

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 single 'bestaetigt' parameter is fully documented in the schema itself. The description repeats the confirmation condition but adds no syntax or format detail beyond what the schema already provides, so the baseline 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?

States a specific verb and resource: it creates the supplied example case (fictional) as a new case, for testing, and assigns the next free identifier. It implicitly distinguishes itself from the generic 'fall_anlegen' sibling through 'Beispielakte' and 'zum Ausprobieren', but does not name an alternative tool explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context ('zum Ausprobieren') and a hard precondition: only with bestaetigt=true after asking the user. No explicit alternative tool is named, but the confirmation gate and testing purpose make the intended usage clear.

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?

Annotation readOnlyHint=false is echoed and enriched: the description details exactly what mutates (new files in 01-08 get an identifier, Finder-moved files are re-found via checksum, missing ordering details are added) and imposes a mandatory confirmation gate. It goes well beyond the annotations, though it doesn't describe reversibility or the response shape.

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?

Front-loaded with the critical 'SCHREIBT IN DIE AKTE' warning, then the operation, then the gating rule. Dense but every clause carries information; only the enumeration of three mutation types makes it slightly long.

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 still conveys what changes and the confirmation requirement, which is what an agent needs before invoking a write tool. Coverage is strong for a 2-parameter tool, with only the meaning of the required 'fall' parameter left partly implicit.

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 only 50%: 'bestaetigt' is fully documented in the schema, but 'fall' has no description. The description implies fall is the case being reconciled and reinforces the bestaetigt gate indirectly, but it does not fully compensate for the undocumented required parameter. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Bestand eines Falls mit den Dateien abgleichen' (reconcile the case inventory against the files). It is distinguishably different from the sibling bestand_pruefen, and the claim 'Der einzige Weg, auf dem neue Dateien registriert werden' further pins down its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear usage condition ('Nur mit bestaetigt=true nach Rückfrage beim Nutzer') and states this is the single path for registering new files, which routes the agent away from pure check tools. It does not explicitly say when to prefer bestand_pruefen instead, so a 4 rather than a 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds useful behavioral context by saying it reports unrecorded and moved files, but 'Schreibt nichts' largely restates readOnlyHint and no further behavior (permissions, timing, scope details) is disclosed.

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 tightly packed clauses that front-load the core action (checksum comparison) and append the reporting behavior and safety note. Every phrase earns its place with 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 simple read-only integrity check with one parameter, no output schema, and annotations covering safety, the description covers what the tool does and what it reports. The main gap is the missing parameter format for 'fall', but the overall context is sufficient 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 0%, so the description must compensate for the single required 'fall' parameter. It only implicitly links the operation to a case ('eines Falls') without explaining expected format, identifier type, or how the case is supplied, leaving the parameter largely undocumented.

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 gives a specific verb and resource: comparing checksums of a case's registered files against the initial state, and reporting unregistered/moved files. It clearly defines scope, but it does not explicitly differentiate itself from the similarly named sibling bestand_abgleichen, leaving a small ambiguity for the agent.

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 gives no guidance on when to use it versus alternatives such as bestand_abgleichen. There is no mention of prerequisites, intended contexts, or exclusions; the agent must infer usage conditions from the purpose alone.

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

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

Annotations only say this is a non-read-only, non-destructive, closed-world write; the description goes well beyond that by declaring 'SCHREIBT IN DIE AKTE', that nothing changes without bestaetigt=true, that the call returns the new P-Kennung, and that document/procedure/deadline references will point at that ID. This is exactly the extra behavioral context annotations cannot carry.

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?

Front-loaded with an uppercase write warning, then purpose, return value and confirmation gate in three tight sentences. Only 'mit Rolle und wahlweise Funktion' mildly restates the schema, so it is near-waste-free.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation with no output schema, the description covers the write side effect, the confirmation gate, and the return value, which is what an agent most needs. Edge cases such as duplicate detection or what happens when required fields are missing are left unaddressed, keeping it short of a 5.

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 75%, so the schema already explains most parameters. The description adds the relationship semantics of the returned P-Kennung and reiterates role/function, but adds no format or syntax detail beyond the schema. Baseline 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?

States a specific verb ('anlegen') and resource ('Beteiligter in einem Fall') and enumerates the entity kinds (Person, Gericht, Behörde, Anwalt, Zeuge, Stelle) plus the role/function attributes. It does not explicitly contrast with the sibling beteiligter_setzen, so the create-vs-update boundary must be inferred from naming.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete precondition: 'Nur mit bestaetigt=true nach Rückfrage beim Nutzer', which tells the agent exactly when the call may proceed. It does not, however, name the alternative tool (beteiligter_setzen) for modifying an existing Beteiligter, so the routing guidance is incomplete.

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 (readOnly=false, destructive=false), the description discloses that this is a write, that only passed fields change (partial update), that the P-Kennung is preserved for referential integrity, and that a confirmation flag gates the write. That is meaningful behavioral context; it lacks detail on the refusal/response path or failure modes, so not a 5.

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 tight sentences with a front-loaded, all-caps warning ('SCHREIBT IN DIE AKTE') that surfaces the risk immediately. Every sentence carries weight, with no 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 9-param write tool with 44% schema coverage and no output schema, the description covers the mutation semantics, the partial-update contract, reference safety, and the confirmation guard. What remains uncovered is minor (e.g., the role of the 'fall' parameter) and largely handled by 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?

Schema coverage is only 44% across 9 params, but the description compensates by enumerating the six mutable fields (Name, Rolle, Funktion, Anschrift, Kontakt, Aktenzeichen) and the P-Kennung-preservation rule. It adds real meaning beyond the schema, though 'fall' and the confirmation mechanics remain thin in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (existing Beteiligten ändern) and enumerates the mutable fields, so the agent knows exactly what the tool does. The word 'Vorhandenen' implicitly distinguishes it from the create sibling beteiligter_anlegen, but the sibling is never named explicitly, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Nur mit bestaetigt=true nach Rückfrage beim Nutzer' gives an explicit precondition/confirmation workflow, which is clear usage guidance. It does not, however, name the alternative sibling (beteiligter_anlegen) or state the when-not case for creation, so it stops short of a 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?

Goes well beyond the annotations: it declares the no-overwrite guarantee ('Überschreibt nie eine vorhandene Datei'), the post-write side effect of registering the file in the Bestand so it receives a D-Kennung, and the confirmation gate that suppresses all changes when bestaetigt is absent. These are exactly the behavioral traits 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?

Front-loads the write intent in a short capitalized lead, then adds four dense sentences covering scope, restrictions, side effects, and the confirmation gate. Nearly every sentence earns its place, with only mild redundancy between the allowed-areas statement and the locked-areas statement.

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 mutation, its restrictions, its side effects, and the confirmation protocol, including what the response contains when confirmation is missing. The only material gap is guidance on how it relates to the overlapping note/draft tools.

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 67%, and the description compensates by explaining the allowed bereich values and, critically, that the other areas are locked out, plus the semantics of the bestaetigt gate and the response when it is false. It adds real constraint meaning beyond the enum itself, though 'fall' and 'unterordner' receive no added context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('SCHREIBT IN DIE AKTE', 'Textdatei in einem Fall anlegen') and names the concrete artifacts it produces (Notiz, Vermerk, Entwurf). It is clear on its own, but it does not distinguish itself from siblings like notiz_anlegen or entwurf_erfassen, whose names overlap with the artifact types it claims to create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition ('Nur mit bestaetigt=true nach Rückfrage beim Nutzer') and a hard scoping rule (only areas 01/06/07; 02-05 and 08 locked). It stops short of routing the agent away from the overlapping siblings, so the when-to-use is clear but the when-to-use-instead is not.

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, so the safety profile is covered. The description adds that the search spans titles, Ordnungsangaben and document contents, but says nothing about result limits, ranking, or whether matching is case/accent sensitive.

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 front-loaded sentence with no filler; the searched-field scope follows the core verb. Nothing extraneous, though it is arguably under-specified rather than maximally efficient.

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 two-parameter read-only search with annotations covering safety and no output schema, the basics are present, but return behavior (result count, ordering, empty-result handling) is absent, leaving gaps an agent would want when calling it.

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 50%: 'frage' is documented with a minimum length, while 'fall' has none. The description's phrase 'eines Falls' at least clarifies that 'fall' scopes the search to one case, partially compensating, but no syntax or format detail is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Volltextsuche) and resource (Dokumente eines Falls), plus the searched fields (Titel, Ordnungsangaben, Inhalte). An agent can distinguish it from dokument_text (single-document retrieval), though the description never names a sibling explicitly.

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?

No when-to-use guidance, no exclusions, and no mention of alternatives such as dokument_text or bestand_pruefen. The agent must infer that this is the entry point for finding documents by keyword.

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=false and destructiveHint=false, and the description is consistent ('SCHREIBT IN DIE AKTE'). It adds genuinely useful context beyond the annotations: the underlying file is not modified (metadata-only write) and the call is gated behind explicit user confirmation — the latter is a behavioral trait no annotation expresses.

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?

Front-loaded with the write intent in capitals, then scope, then invariants and gating. The long parenthetical field list is dense but it is the payload that makes the tool callable, so it earns its space.

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 gated mutation with no output schema and a nested 'felder' object, the description covers what is changed, what is not changed, and the confirmation requirement (also reinforced in the schema for bestaetigt). Missing only a pointer on how field keys map to expected values for non-Textstand fields.

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 50% and the description compensates by enumerating the permissible 'felder' keys (Titel, Datum, Art, Stand, Themen, Anlage, Personen, Verweise, Notiz, Textstand) including the accepted values for Textstand. It leaves 'fall' and 'dokument' unexplained, but the hardest-to-guess parameter is meaningfully documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (Ordnungsangaben eines Dokuments ändern) and enumerates exactly which metadata fields are affected. The clause 'Die Datei selbst bleibt unverändert' cleanly separates it from siblings like dokument_verschieben or datei_ablegen that touch the file itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition: only call with bestaetigt=true after asking the user. It does not name alternative tools or say when metadata ordering is not the right action, but the gating condition is clear enough that the agent knows the required 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?

Annotations already declare this is a safe, non-destructive, closed-world read. The description adds genuinely useful behavioral context beyond that: it explains the provenance fields (textquelle = direct / PDF layer / not read at all, e.g. image scan; textstand = recorded reading quality) and flags that the excerpt is derived and may be unreliable for numbers and deadlines.

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?

Front-loads what the tool returns and then explains the provenance fields, with the verification caveat last. It is one dense run-on sentence, but every clause carries information and nothing is redundant.

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 does the work of explaining the return shape (textquelle, textstand) and the reliability caveat, which is exactly what an agent needs to interpret the result. The remaining gap is the undocumented 'fall' parameter.

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 50% — only 'dokument' is described (as a D-Kennung like D0038). The description adds no meaning to either parameter; 'fall' is entirely undocumented in both schema and description, and the discussion of textquelle/textstand refers to return fields, not inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (extracts a text excerpt) and resource (a document), and enumerates supported formats (Word, E-Mail, PDF, Text, HTML). It is clearly distinguishable from siblings like texterkennung (OCR) and dokumente_suchen (search), since this tool reads one document's text with provenance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied — read the text of a given document — and the description usefully warns that the excerpt is a derivative and numbers/deadlines should be verified at the original. But it names no explicit alternative or when-not condition relative to texterkennung or dokument_ordnen, so routing relies on inference.

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=false and destructiveHint=false; the description reinforces this by stating the Kennung and content are preserved and nothing is overwritten, and adds the human-confirmation workflow. It does not cover error cases or what happens on invalid bereich values.

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, front-loaded with the write warning 'SCHREIBT IN DIE AKTE', then the operation, then the invariant, then the confirmation gate. 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 mutation tool with no output schema and no destructive annotation, the description covers the safety-critical facts (writes to file, preserves content, requires confirmation). Only the bereich/unterordner parameter semantics remain thin.

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 only 40%, so the description must compensate. It adds meaning for bestaetigt (confirmation semantics) and implies fall/dokument are stable identifiers, but says nothing about the bereich enum or the optional unterordner, leaving gaps the schema also only partially covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: moving a file into a different Aktenbereich ('Datei in einen anderen Aktenbereich einsortieren'). This distinguishes it from datei_ablegen (filing new) and dokument_ordnen, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete usage condition: only call with bestaetigt=true after asking the user. This is a clear gating rule for when the tool may be invoked. No alternative tools are named, so it falls short of a full 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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description goes well beyond by explaining versioning rules, checksum-based decisions, freezing behavior for 'geprüft'/'versandt', creation of immutable copies, and the required user confirmation, giving rich behavioral 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?

The description is front-loaded with a clear mutation warning ('SCHREIBT IN DIE AKTE') and proceeds logically through versioning and status rules. It is dense but every sentence carries operational meaning; minor improvement could come from bullet-like separation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 8-parameter mutation tool with no output schema, the description covers core behavior, versioning, freezing, and confirmation requirements well. It still leaves gaps around the fall and versandt_als parameters and does not describe the response when bestaetigt is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 63%, and the description adds useful meaning for titel, fassung_behalten, fassung_nach_text, and bestaetigt, including interaction rules. However, it omits any explanation of fall or versandt_als, leaving some parameters undocumented in both description and 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?

States a specific verb (erfassen/fortschreiben) and resource (Entwurf in der Akte), making the tool's function clear. However, it does not explicitly differentiate from the sibling tool entwurf_setzen, so sibling selection remains ambiguous.

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 an important usage condition: only with bestaetigt=true after asking the user. It also implies when statuses trigger freezing, but does not compare against alternatives or state when not to use this tool versus siblings.

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

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

Annotations already declare a non-read-only, non-destructive write, so the baseline bar is lower. The description adds genuinely useful side-effect detail (the W-ID, versions and frozen copies remain; copies inherit the new title) and the confirmation gating, but is silent on permissions, reversibility of the title change, and error behavior. It adds real context beyond annotations without fully covering the mutation's 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?

Four tightly packed sentences, each carrying distinct information (scope, mutation target, preserved entities, confirmation gate), with the write action front-loaded. 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 mutation tool with no output schema, the description covers the write semantics, the invariants it preserves, the routing to the sibling, and the confirmation requirement. An agent has what it needs to call 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?

With 75% schema coverage the baseline is 3, and the description reinforces the meaning of both titel and bestaetigt (mandatory user confirmation before anything changes, otherwise the response carries the follow-up question), which goes beyond the schema text. The fall parameter is undocumented in both places, which keeps this from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: changing the title of an existing draft (Entwurf), opening with the emphasized "SCHREIBT IN DIE AKTE" framing. It explicitly names the sibling entwurf_erfassen as the tool that still handles status/file changes, so an agent can separate the two without opening schemas.

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?

Names the alternative (entwurf_erfassen) and the exact condition that routes to it (status and file changes). It also states a clear precondition: only call with bestaetigt=true after asking the user, which is explicit when/when-not 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 declare this is a non-read-only, non-destructive write, but the description adds genuinely non-structured behavior: it writes into the case file and requires a two-step confirm-after-asking flow, with nothing changed unless bestaetigt=true. It does not describe failure modes or what the response contains when unconfirmed, keeping it below 5.

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?

Front-loaded with the operation type ('SCHREIBT IN DIE AKTE') and kept to three sentences. The middle field enumeration is long but functional; 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 23-parameter mutation tool with no output schema, the description covers the operation, the field scope, and the critical confirmation gate. It omits any statement about the return payload or behavior on rejection, which would fully close the loop.

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 83%, so the schema already carries most parameter meaning. The description's field list (Zeitpunkt, Überschrift, Art, Darstellung, Kernereignis, Personen, Belege, Betrag, Belegstand, Terminstatus) largely recaps those properties without adding format or constraint detail 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?

States a specific verb+resource ('Ereignis in die Chronologie eines Falls eintragen') and enumerates the fields it populates, so the action is unmistakable. It does not, however, distinguish itself from the sibling ereignis_setzen, which an agent would reasonably confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition — only call with bestaetigt=true after asking the user — which is actionable usage guidance. It stops short of stating when to prefer this over ereignis_setzen or other sibling write tools, so it is not a 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 annotations, the description discloses crucial mutation semantics: partial updates (only passed fields change), that 'zeitpunkt=genau' strips uncertainty data, and that an empty value deletes a listed chronology field. This is exactly the kind of behavior an agent needs before writing to a case file.

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?

Front-loaded with the most important fact ('SCHREIBT IN DIE AKTE') and then layers update semantics and the confirmation rule. It is dense but each clause carries distinct information; only the run-on German phrasing slightly reduces readability.

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?

No output schema exists, and the description does cover the confirmation response ('die Antwort enthält dann die Rückfrage'). For a 24-param update tool, the safety and update semantics are adequately covered, though detail on the full parameter set is not.

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 67% across 24 params, so the schema carries much of the load. The description nonetheless adds meaning the schema does not: the empty-value-clears-field rule for a named group of chronology fields and the special behavior of 'zeitpunkt'. Many parameters remain unexplained, so it is helpful but not exhaustive.

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+resource ('Vorhandenes Ereignis ändern' – change an existing event), and the word 'Vorhandenes' implicitly distinguishes it from the sibling ereignis_eintragen (create). It is clear what the tool does, though it never names the create-alternative explicitly.

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 confirmation gate is stated well ('Nur mit bestaetigt=true nach Rückfrage beim Nutzer'), which is a genuine usage rule. However, there is no explicit when-to-use-vs-ereignis_eintragen routing and no exclusions; the 'existing event only' scope 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety and locality are covered. The description adds useful output content by listing the fields returned, but does not disclose pagination, ordering, or other behavioral traits beyond what annotations provide.

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 listing the returned fields with no filler. It is appropriately sized for a no-parameter listing tool, though it is a fragment rather than a full 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?

With no output schema and no parameters, the description carries the burden of explaining return values and does so by enumerating the fields. It is nearly complete for this simple list-all tool, though it could mention ordering or scope (e.g., all cases regardless of status).

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 correctly does not attempt to describe parameters, and there are no parameter semantics to clarify.

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 all cases and enumerates the returned fields (Kennung, Titel, Bereich, Status, Zahl der Dokumente, nicht erfasste Dateien, offene Aufgaben). It does not explicitly distinguish itself from sibling tools like fall_uebersicht, but the verb+resource is specific enough for an agent to understand its 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?

There is no guidance on when to use this tool versus alternatives such as fall_uebersicht or dokumente_suchen. The description only describes the output, leaving usage context entirely 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?

Annotations only declare this is a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds meaningful behavioral context: it writes into the case file ('SCHREIBT IN DIE AKTE'), creates a fixed identifier plus folder structure, and enforces a confirmation gate that blocks the write without bestaetigt=true. It still omits error/return behavior, but that is a smaller gap given annotation coverage.

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 short sentences, front-loaded with the critical write warning in caps, then the action, then the confirmation constraint. No filler; only slight gain possible from naming the key parameters.

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 5-parameter mutation with no output schema and 40% schema coverage, the description covers the safety-critical confirmation requirement and the folder/ID side effect, but leaves what titel, ziel, and bereich control, and what the tool returns, unexplained. Adequate but with clear gaps.

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 only 40% (rolle and bestaetigt documented, ziel/titel/bereich not). The description only restates the bestaetigt condition already present in the schema and adds no meaning for titel, ziel, or the large bereich enum, so it fails to compensate for the low 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?

States a specific verb+resource: 'Neuen Fall mit fester Kennung und Ordnerstruktur anlegen' – creating a new case with a fixed identifier and folder structure. It does not distinguish itself from similar siblings such as verfahren_anlegen, but the action and artifact are 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 one important precondition – only call with bestaetigt=true after asking the user – which is real usage guidance. However, it offers no when-to-use context relative to the many sibling creation tools (verfahren_anlegen, beteiligter_anlegen, etc.), leaving selection largely to inference.

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=false and destructiveHint=false, so the safety profile is partly given. The description adds real context beyond them: it is a write, the case 'bleibt am gleichen Ort' (non-destructive of location/folder), and it requires explicit user confirmation before acting.

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 terse sentences, no waste, front-loading the write warning ('SCHREIBT IN DIE AKTE') and the status targets ahead of the confirmation rule. Ideal structure for a high-scrutiny mutation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter mutation with no output schema, the description covers the write nature, effect (location unchanged), and confirmation precondition; the schema handles the retry/response behavior. Only the 'fall' parameter's format is left totally unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, so the description should compensate. It does restate the status enum values (already in the schema) but adds nothing about the 'fall' parameter's expected identifier format. bestaetigt is fully documented in the schema, so the net value beyond structured data is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (Fallstatus setzen) plus the exact enum target values (offen, ruhend, abgeschlossen), and 'SCHREIBT IN DIE AKTE' signals the write nature up front. An agent can distinguish it from verfahren_setzen, aufgabe_setzen and other *_setzen siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete prerequisite and workflow: 'Nur mit bestaetigt=true nach Rückfrage beim Nutzer', i.e., confirm with the user before calling. It lacks explicit when-to-use-vs-alternatives routing (e.g., vs fall_anlegen), so it stops short of a 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing the breadth of the returned aggregate (parties, proceedings, deadlines, tasks, events, document list with Kennung/Titel/Datum/Stand, plus uncaptured files). It does not discuss pagination, volume limits, or auth requirements, keeping it below 5.

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 compact sentences, front-loaded with the overview scope and followed by the routing note. Every clause earns its place by naming a returned data category; 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?

With no output schema, the description carries the burden of describing return contents, and it does so thoroughly by enumerating the sections of the overview. Only minor gaps remain (volume, ordering, or handling of missing/uncaptured data), so it is nearly complete for a single-parameter read tool.

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% and the single 'fall' parameter is documented in the schema as 'Fallkennung wie R-0001'. The description adds no syntax, format, or constraint details beyond that, so the baseline of 3 for a fully-covered schema 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?

Names a specific resource (Fall) and an aggregation verb (Übersicht) and enumerates exactly what the overview contains: Beteiligte, Verfahren, offene Fristen/Aufgaben, Ereignisse, Dokumentliste, nicht erfasste Dateien. It also names the sibling (dokument_text) for a capability it deliberately excludes, so an agent can distinguish it from other case tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing sentence 'Dokumentinhalte über dokument_text' explicitly routes document-content retrieval to an alternative, which is clear usage guidance. It does not, however, state when-not to call this tool (e.g. cost/scope limits) or mention other case-listing siblings like faelle_auflisten.

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/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns the calculation as text (important since there is no output schema), defaults land to the map setting, and disclaims any normative decision. It stops short of describing edge-case handling.

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 tight sentences: what it computes, what it returns, what it deliberately does not decide. No filler, and the scope-limiting clause is positioned last where it is most useful.

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 correctly covers the return type (text). For a 6-parameter calculator it is nearly complete, though it does not describe output format details or behavior on invalid land/date inputs.

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 67%, so most parameters are self-documented; the description adds meaning by tying land to nationwide holidays and by invoking §§ 187/188/193, which is exactly the legal logic that governs ereignisfrist and werktagsregel. It adds nothing for menge/einheit, but those are self-evident counting inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Fristende ... berechnen") and grounds it in concrete law (§§ 187, 188, 193 BGB) plus the holiday-of-state qualifier. Explicitly carve-outs its scope with "Entscheidet nicht, welche Frist gilt", which cleanly separates it from siblings like frist_setzen and frist_eintragen.

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 closing sentence tells the agent what this tool will not do — decide which deadline applies — which implicitly routes that question elsewhere. However, it never names an alternative sibling or states prerequisites (e.g. that start/menge/einheit must already be known), so guidance is contextual 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?

Adds substantial behavior beyond the annotations (readOnlyHint=false, destructiveHint=false): it enumerates the exact conditions under which a confirmation will be accepted (calculation names the deadline end, trigger, legal basis and source present, no open [PRÜFEN]/[QUELLE]/[BELEG] markers), and states the confirmation receives a review date and reviewer. This is genuinely rich behavioral disclosure for a mutation 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?

Front-loads the most important fact ('SCHREIBT IN DIE AKTE') and then packs the gating rules into a compact semicolon-joined sentence. Dense but every clause carries an actionable constraint; 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 13-parameter mutation tool with no output schema and low schema coverage, the description covers the critical gating logic and the no-op behavior when bestaetigt is absent. It stops short of documenting remaining parameters, but the safety-critical context an agent needs 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?

Schema description coverage is only 38% across 13 params, so the description must compensate. It ties meaning to several params — berechnung ('Rechnung das Fristende'), ausloeser, rechtsgrundlage, quelle, and the bestaetigt gating — but many others (art, fall, datum, titel, verfahren, pruefstatus, geprueft_von, ausloeser_ereignis) are left to the schema. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Frist oder Termin in einem Fall eintragen', with the all-caps 'SCHREIBT IN DIE AKTE' reinforcing that this is a write. An agent can tell it writes a deadline/appointment to a case file. It does not, however, differentiate from the sibling 'frist_setzen', leaving some ambiguity about which write tool to choose.

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 one strong precondition — 'Nur mit bestaetigt=true nach Rückfrage beim Nutzer' — which tells the agent this call must be user-confirmed. But there is no explicit guidance on when to use this versus siblings like frist_setzen or ereignis_eintragen, so usage is only partially 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?

Adds real behavioral context beyond annotations: "Nur die übergebenen Felder werden geändert" documents patch/partial-update semantics (consistent with destructiveHint=false), and the confirmation flow ("Eine Bestätigung bekommt Prüfdatum und Prüfer") plus the reconciliation step ("das Schema prüft ... Rechnung, Beleg und offene Marker") are disclosed. Does not cover rate limits or error 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?

Dense, front-loaded opening ("SCHREIBT IN DIE AKTE") and every clause adds a distinct fact (scope, patch behavior, confirmation metadata, confirmation gate). Slightly jargon-heavy and terse, but no filler sentences.

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 14-parameter write tool with no output schema and low schema coverage, the description covers the critical confirmation workflow and even mentions the non-confirmed response ("die Antwort enthält dann die Rückfrage"). However, most field semantics remain undocumented, leaving real gaps for an agent filling out this call.

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 only 36% across 14 parameters, so the description should compensate but largely does not. It explains the confirmation gate (bestaetigt), the review metadata (Prüfdatum/Prüfer) and the partial-update rule, but the majority of parameters (art, titel, berechnung, rechtsgrundlage, etc.) get no added meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ("SCHREIBT IN DIE AKTE") and resource ("Vorhandene Frist oder vorhandenen Termin ändern"), so the agent knows this mutates an existing deadline/appointment. The verb "ändern" implicitly distinguishes it from the insert-style sibling frist_eintragen, but no sibling is named outright.

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 a clear gating condition: "Nur mit bestaetigt=true nach Rückfrage beim Nutzer" — the tool should only be invoked after user confirmation. "Vorhandene ... ändern" also signals the precondition that a deadline must already exist. It does not explicitly name an alternative tool, so no exclusions are given.

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 openWorldHint=false, so the safety profile is covered. The description adds useful context beyond annotations: the data source is JOURNAL.md and entries are returned oldest-to-newest-last. It does not say what happens if no journal exists for the case.

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 front-loaded sentence with zero filler; the data source and ordering constraint are both stated compactly and nothing is repeated from the schema or annotations.

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 single-parameter read tool with annotations covering safety and no output schema, the description is close to adequate. Gaps remain on the 'fall' identifier format and on behavior when the journal is missing or very large, which the schema and annotations do not cover.

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 0% for the single 'fall' parameter. The description implies 'fall' selects which case's journal to read ('Verlauf eines Falls'), which adds some meaning, but gives no format hint (case ID vs. name) to compensate for the undocumented 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?

Names a specific verb+resource: reading a case's history from JOURNAL.md, plus the ordering of results. The read counterpart to the sibling journal_schreiben is inferable from the name, but the description does not explicitly distinguish itself from other case-reading siblings like fall_uebersicht.

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?

No statement of when to use this versus fall_uebersicht, dokument_text, or any other read tool, and no prerequisites (e.g., journal must exist). Usage is only implied by the name and the mention of JOURNAL.md.

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

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

Annotations already declare a non-read-only, non-destructive, closed-world write, and the description adds the crucial gate: nothing is written unless the user has explicitly confirmed this exact call. This confirmation requirement is behavioral context beyond the annotations. It does not describe the result of a successful write or any permission requirements, so not a 5.

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 short, front-loaded sentences with zero padding; the write warning leads. The all-caps opening is emphatic but arguably earns its place for a mutation tool. Nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an append-only tool with no output schema, the description covers the write action, its scope (a case journal) and the confirmation precondition. Remaining gaps (success response, whether entries are editable afterwards) are minor given annotations already cover the safety profile.

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 only 20% (just bestaetigt), so the description should carry more of the load, but it says nothing about fall, art, titel or text. The confirm-gate sentence only restates what the schema already documents for bestaetigt. Field names and the art enum are largely self-explanatory, which keeps this from a 1.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Eintrag an das Journal eines Falls anhängen'), so an agent knows this appends a journal entry to a case. The verb 'anhängen' implicitly distinguishes it from the sibling journal_lesen, though that sibling is never named. Clear but not fully differentiated by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition: only call with bestaetigt=true and only after asking the user. That is real when-to-use guidance. It stops short of naming alternatives (e.g. journal_lesen for reading) or saying when not to use it at all.

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=false, consistent with the description's 'SCHREIBT IN DIE AKTE'. Beyond that, the description discloses a genuine behavioral trait the annotations do not: the confirmation gate requiring bestaetigt=true after user consultation. It does not state permissions or reversibility, so not a 5.

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 short, front-loaded sentences with zero filler: the write action is capitalized first, then the operation, then the guard condition. Every clause 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 mutation tool whose annotations already cover the safety profile and with no output schema to explain, the description supplies the key operational constraint (confirmation before writing). The gap is the undocumented titel/text parameters.

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 only 25% (only bestaetigt is described), so the description must carry weight. It implies fall = the case ('in einem Fall') and restates the bestaetigt condition, but adds no meaning for titel or text. Baseline 3 is appropriate given the partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Ordnungsnotiz in einem Fall anlegen' plus the emphasized 'SCHREIBT IN DIE AKTE'. An agent knows this creates an organizational note on a case file. It does not explicitly name a sibling, so it falls short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete precondition for use: 'Nur mit bestaetigt=true nach Rückfrage beim Nutzer' — the note may only be written after confirming with the user. It does not compare against alternatives (e.g., journal_schreiben or entwurf_erfassen), so it is not a 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 only declare the write/open-world/destructive triad; the description adds material behavior beyond that: same title overwrites an existing entry (upsert semantics) and the write only proceeds after explicit user confirmation. It omits return-shape detail, though the bestaetigt schema note partly covers the 'no confirmation' response.

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?

Front-loaded with the operation ('SCHREIBT IN DIE AKTE') and then the resource, sibling routing, overwrite rule, and confirmation gate. Dense but every sentence carries a distinct constraint; 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 mutation tool with no output schema and only basic annotations, the description supplies routing, overwrite semantics, and the confirmation gate. Return behavior is only implied via the bestaetigt schema note, but nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 83%, so the schema carries the parameter burden. The description paraphrases titel (Norm/Entscheidung) and geprueft (Abrufdatum) but adds no format or validation detail beyond the schema, so baseline 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?

States a specific verb+resource ('Fallbezogene Rechtsquelle in der Akte vermerken') and enumerates the payload (Norm, Entscheidung, amtliche Seite mit Abrufdatum). It explicitly names the sibling it is NOT for ('der gemeinsame Zugangskatalog ... Werkzeug quellen_katalog'), so an agent can separate it from quellen_katalog without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing context: case-bound sources go here, shared-catalog sources go to quellen_katalog. It also states the confirmation precondition ('Nur mit bestaetigt=true nach Rückfrage beim Nutzer'). No explicit exclusion list beyond the catalog split, but the when-to-use is well covered.

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 openWorldHint=false, so the safety profile is covered. The description adds one useful piece of context the annotations cannot: the data is drawn from '04 Rechtsquellen/Quellen.md'. It says nothing about return format or freshness, so it adds moderate rather than rich 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?

A single compact sentence with the source location front-loaded and no filler. It is appropriately sized, though the noun-phrase construction makes it slightly less actionable than a verb-first phrasing would be.

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 adequate: it names the resource and its backing file. It still omits what the catalog returns (entries, fields, structure), which is the one thing an agent would want before invoking it.

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 zero parameters and the schema is empty, so there is no parameter semantics to explain. Baseline 4 applies; the description neither helps nor harms here.

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 identifies the resource (a shared access catalog of official legal sources) and even names its backing file, but it uses a noun phrase rather than a verb, so it never states what the tool actually does (return/list/read). It does not distinguish itself from the related sibling quelle_eintragen, which handles entering sources.

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?

There is no statement of when to call this tool, when not to, or which sibling to prefer instead. The only implicit cue is 'Zugangskatalog', leaving the agent to infer that this is the read side versus quelle_eintragen's write side.

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 annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, and the description reinforces this with "Schreibt nichts, ohne Netz." Beyond that, it discloses the review intervals and the possible status values (fällig, bald fällig, unbekannt, in Ordnung), which are useful behavioral details not present in 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 a single dense sentence that front-loads the core purpose and then packs in the relevant rules and status values without filler. Every clause earns its place, and there is no redundant or decorative language.

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 reporting tool with no output schema, the description supplies the necessary return semantics by listing the possible statuses and the review rules. The only parameter is fully covered by the schema, and the annotations cover safety, so no important context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the sole optional parameter "stichtag" is fully documented in the schema as a date in JJJJ-MM-TT format with default today. The description does not add any parameter-specific meaning, 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 uses a specific verb ("Meldet") and resource ("mitgelieferten Rechtsinhalte") and states exactly what is reported: which legal contents need re-checking against the official full text. It also names the content categories and review intervals, making the tool's purpose unambiguous and distinguishable from generic inventory or document 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 the tool is used for compliance review of supplied legal content, but it does not explicitly state when to use it versus alternatives such as bestand_pruefen or quellen_katalog. The context is clear enough to infer intended use, but no exclusions or alternative routing are provided.

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=false, destructiveHint=false and openWorldHint=false, and the description is consistent with them. Beyond that it discloses the confirmation gate and a side effect not captured by annotations (a copy to the second target), which is genuinely useful behavioral 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?

Three short sentences, front-loaded with the mutation warning ('SCHREIBT IN DIE AKTE') followed by what is produced and the gating condition. 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?

With no output schema, the description covers the write action, the artifact produced, the secondary copy, and the confirmation requirement. It could say more about what happens on failure or what the non-confirmed response looks like, but the essentials are 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?

Schema coverage is 100% and the schema already explains bestaetigt in detail, so the baseline is 3. The description still adds the workflow meaning — that true is required and only after a user check — reinforcing the schema's semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: create a verified ZIP backup of the whole project plus a copy to a second target. It is distinguishable from the sibling sicherung_probe (a probe/test) by the word 'Geprüfte' and by naming the copy step, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear precondition: only call with bestaetigt=true and only after asking the user ('nach Rückfrage beim Nutzer'). It does not, however, point to alternatives like sicherung_probe for a dry run, so the routing guidance is incomplete.

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=false and destructiveHint=false, and the description adds real value beyond them: it discloses that it writes into the Akte, creates and deletes a temp folder, verifies checksums, leaves the Mappe untouched, and requires user confirmation. The distinction between the written Akte and the untouched Mappe is useful, though the exact nature of the write could be sharper.

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 critical mutation warning ('SCHREIBT IN DIE AKTE') is front-loaded, and the sequence of operations is described compactly. Slightly dense with some overlapping clauses, but no wasteful padding.

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 usefully explains the return semantics ('bestanden' for archive completeness, 'aktenfehler' for data-model violations), which is what an agent needs to interpret results. It is nearly complete, though a bit more on what the Akte write records would close the 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%, so both parameters (archiv, bestaetigt) are already documented in the schema. The description only reinforces the confirmation workflow around bestaetigt and adds no syntax or format detail beyond the schema, 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 names a specific verb and resource: a restore probe that unpacks the last backup into a temp folder, verifies records against the schema and files against checksums, then removes the temp folder. This is unmistakably distinct from sicherung_erstellen and other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the key precondition clearly – only run with bestaetigt=true after asking the user – which is exactly the when-to-use guidance an agent needs for a mutating tool. It does not name an alternative tool or an explicit when-not, so it falls short of a 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?

Goes well beyond the annotations: discloses exactly what is created (new text file with D-Kennung, source reference, header with checksum, program, language, date, warning), where it lands (07 Recherche/Texterkennung), that the original is never modified or overwritten, and that a text-status marker is set on the original. It also warns that OCR output is a derivation whose numbers, dates, deadlines and amounts must be verified at the original.

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 dense paragraph that front-loads the critical mutation warning ('SCHREIBT IN DIE AKTE') and then flows through preconditions, side effects, and verification caveats. Lengthy, but nearly every clause carries operative 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 mutation tool with no output schema, the description covers preconditions, confirmation gate, artifacts produced, original-file preservation, and downstream verification duties. An agent has everything needed to call it 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?

Schema coverage is 75%, so most parameters are documented structurally. The description adds meaning beyond the schema for bestaetigt (an explicit user-confirmation gate) and for dokument (must be a photo or text-layer-less PDF), though it never explains the fall parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: performs OCR on a photo or text-layer-less PDF via tesseract, and writes the result into the case file as a new text file. It also implicitly distinguishes itself from the sibling dokument_text (which reads existing text) by requiring a document *without* a text layer.

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?

Clearly states the precondition for use (photo or PDF without a text layer) and the hard gate: only with bestaetigt=true after asking the user. It does not name a sibling alternative explicitly, so it falls just short of the top mark.

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 emphasized "SCHREIBT IN DIE AKTE" and the confirmation gate (nothing changes without bestaetigt=true; the response then carries the counter-question) disclose mutating behavior and a safety workflow well beyond the readOnlyHint=false/destructiveHint=false annotations. It does not contradict the annotations, since a create is a write but not destructive. Remaining gaps are minor for 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?

Four short clauses, front-loaded with the all-caps write warning, then purpose with examples, then the definition that disambiguates a Verfahren, then the confirmation condition. No filler sentences and the most consequential constraint (the write) comes first.

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, 2-required mutation tool with no output schema and no destructive annotation, the description covers the essential: what is written, what counts as a Verfahren, and the confirmation gate that governs execution. It leaves return format and the non-required fields (ordner, stelle, stand) to the schema, which is acceptable given the schema documents them.

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 71%, and the schema already documents the two highest-risk parameters thoroughly (art's example list, bestaetigt's full semantics). The description's type list for Verfahren duplicates the art field rather than adding syntax or format guidance, so the schema carries the semantic load. 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?

States a specific verb and resource ("Verfahren in einem Fall anlegen") with concrete examples (Klage, Bußgeldverfahren, Widerspruch, Mahnverfahren, Strafanzeige) and even defines the boundary criterion ("eine eigene Stelle und ein eigenes Aktenzeichen"). The scope is unmistakable, though it never explicitly distinguishes creating a new Verfahren from the sibling verfahren_setzen, which an agent comparing the two would need.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a hard prerequisite for use: "Nur mit bestaetigt=true nach Rückfrage beim Nutzer," which tells the agent exactly when the call is allowed to take effect. It does not name an alternative sibling or state when not to create a Verfahren (e.g. when one already exists), 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 declare write (readOnlyHint=false) and non-destructive, but the description adds substantial context: partial-update semantics ('nur die übergebenen Felder werden geändert'), ID stability and its rationale ('V-Kennung bleibt, damit Fristen ihren Bezug behalten'), and a mandatory confirmation gate. This goes well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the warning 'SCHREIBT IN DIE AKTE.' followed by three tight sentences covering scope, update semantics, and the confirmation requirement. No filler; 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?

No output schema exists, but the description covers the mutation contract, ID preservation, and even the response behavior when unconfirmed ('die Antwort enthält dann die Rückfrage'). Minor gaps remain around validation failures or permission requirements, but the core is complete for an update tool.

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 63%, with art, fall and aktenzeichen undocumented in the schema. The description compensates by explaining the partial-update contract (only passed fields change) and the confirmation parameter's effect, though it does not add format details for the unspecified fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Vorhandenes Verfahren ändern') and implicitly differentiates from the create sibling verfahren_anlegen by specifying the procedure must already exist. Enumerates the mutable fields (Art, Stelle, Aktenzeichen, Stand, Ordner) so an agent knows the scope without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the precondition for acting ('Nur mit bestaetigt=true nach Rückfrage beim Nutzer'), which is clear usage context. It does not name alternatives such as verfahren_anlegen for the new-record case, leaving that to inference.

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?

Adds substantial behavior beyond annotations: it writes into the case file, copies to 06 Entwürfe, never overwrites, fills only four specific placeholders while leaving others blank, and gates execution on user confirmation. This complements destructiveHint=false with concrete 'what gets created / what stays untouched' detail.

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?

Front-loaded with the all-caps 'SCHREIBT IN DIE AKTE' write indicator, then destination and placeholders. The placeholder enumeration is dense but earns its place; overall efficient with little waste.

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 whose annotations already declare the safety profile and with no output schema, the description covers destination, non-overwrite, placeholder filling, and the confirmation gate. An agent has enough to call 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?

Schema coverage is 75% and the schema already documents ziel's default naming and bestaetigt's meaning. The description mainly restates the confirmation flow and template source rather than adding syntax or format detail beyond the structured fields, so it stays near 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?

States a specific verb+resource: creates a draft from a writing template and copies it to '06 Entwürfe' of the case. It distinguishes itself from siblings entwurf_erfassen/entwurf_setzen by being template-driven and references vorlagen_auflisten for the source name.

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?

Clearly states the precondition 'Nur mit bestaetigt=true nach Rückfrage beim Nutzer' and points to vorlagen_auflisten for template names. It gives context but does not explicitly contrast when to choose this over entwurf_erfassen or entwurf_setzen.

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, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds useful context about scope (templates under '05 Vorlagen/Schreiben') and output content ('mit erster Zeile'), but does not discuss permissions, pagination, or return format details 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?

It is a single short sentence with no filler, but it is a fragment rather than a front-loaded action statement, making it less immediately parseable. The parenthetical examples are terse and slightly ambiguous.

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 list tool with no output schema, the description gives the folder scope and hints at returned content ('erste Zeile'), but it does not explicitly state that a list of templates is returned or clarify the meaning of 'interne Hinweise, Merkblatt'. It is minimally adequate but leaves room for ambiguity.

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 zero parameters, so the baseline is 4. The description adds no parameter information, which is appropriate since the schema is empty and 100% covered.

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 is a noun phrase ('Schreibvorlagen unter 05 Vorlagen/Schreiben mit erster Zeile...') that specifies the resource and folder scope but omits an explicit action verb like 'auflisten' or 'list'. It distinguishes the tool from siblings by narrowing to writing templates under a specific path, but the purpose is implied rather than stated outright.

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?

There is no guidance on when to use this tool versus alternatives such as vorlage_fuellen or other list tools. The folder path gives some context but does not explain selection conditions or exclusions.

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