Sessionario

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

Beyond the annotations, the description discloses important runtime behavior: attachments without 'tag and nummer go to the session, limits are 50 attachments per session and 50 MB per file, storage-plan errors are reported in plain text, and deletion is not supported via this tool. This is substantial behavioral context beyond the structured annotations.

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

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

Though longer than average, the description is well structured and front-loaded with the core action, then rationale, then placement, duplicate, limit, and error information. Every sentence adds operational value rather than restating the schema.

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

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

The description is complete for a mutation tool with no output schema: it covers what the tool does, when to use it, placement rules, limits, failure behavior, and how attachments are removed. An agent can correctly invoke it with confidence.

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 a baseline of 3 applies. The description adds extra value by explicitly explaining the combined effect of 'tag' and 'nummer' on placement at the session level, and by grounding the duplicate-check behavior in 'session_lesen'. That pushes it above the baseline.

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

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

The description opens with a precise verb and resource: 'Hängt eine Datei an ein Modul oder an die ganze Session' and gives concrete examples. It clearly distinguishes this tool from the sibling module/session management tools because it uniquely handles file attachments.

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

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

It explains the intended use case explicitly: large files referenced by an imported guide should be attached rather than put in 'material'. It also gives when-not guidance: check 'session_lesen' under 'anhaenge' before sending duplicates, and notes removal is only possible in the app.

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?

While annotations already cover the read-only/idempotent safety profile, the description adds substantial behavior the annotations do not: exactly which formats yield readable text, that scanned PDFs/images return a hint rather than empty text (and what the agent should tell the user), and how pagination works via zeichen_gesamt/gekuerzt/ab.

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 core purpose, then cleanly sectioned into what can be read, what cannot, where the id comes from, and pagination. Despite its length, every section carries actionable information for a genuinely multi-faceted 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?

Even without an output schema, the description discloses the relevant return fields (zeichen_gesamt, gekuerzt) and the error behavior for unreadable files. Combined with full schema coverage and annotations, an agent has everything needed 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 100%, so baseline is 3. The description goes beyond the schema by explaining that 'anhang' should be the id from session_lesen (with the filename caveat about non-uniqueness) and by explaining how 'ab' is used to continue reading a long file.

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 (reads the CONTENT of an attached file) and immediately distinguishes itself from mere name listing. It is clearly separable from siblings like session_lesen (which lists attachments) and anhang_hinzufuegen (which adds them).

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 concrete when-to-use context (working with a work order, sample solution, or handout: summarize, answer questions, build a session) and a strong when-not section for scanned PDFs and images. It points to session_lesen for the attachment id rather than naming a true alternative tool for the same task, so it falls just short of full explicit routing.

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?

Far exceeds the annotations: it discloses that 'loesen' moves a module behind the block and auto-removes the roof when one module remains, that 'aufloesen' destroys the roof's Name/Ziel/Inhalt, that 'verbinden' leaves the title empty, that optional blocks require modul_aendern with optional:true, and that the roof's time is computed from children. The only tension is that destructiveHint=false while 'aufloesen' wipes roof metadata, but the loss is confined to grouping metadata (modules survive), so this is documented side-effect disclosure rather than a flat contradiction.

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 long, but the length is front-loaded with the single most decision-relevant fact (block vs. parallel group) and structured with bullets. A few time-arithmetic examples are slightly verbose, but each section carries distinct, non-redundant 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 5-parameter, no-output-schema mutation tool, the description covers the full lifecycle: how to connect, dissolve, and merge blocks, how to subsequently name an optional block, and how time is computed. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description nonetheless adds real meaning beyond the schema by explaining how 'nummer' is interpreted per action (upper module, roof, submodule) and by detailing the merge scenario that uses 'nummer' + 'mit_nummer' as two roofs.

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 concrete verb+resource ('mehrere Module NACHEINANDER unter einem gemeinsamen Dach') and immediately distinguishes itself from the sibling parallelgruppe_setzen by naming it and stating the exact axis of difference (GLEICHZEITIG vs NACHEINANDER). An agent can tell this apart from any sibling 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?

It explicitly names the alternative tool and the condition that selects each (parallel = simultaneous, block = sequential), then spells out when to use each of the three actions (verbinden/loesen/aufloesen) including the two-block merge case. Exclusions and prerequisites are stated rather than left 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 cover the safety profile (readOnly=false, idempotent=true, destructive=false), and the description adds genuine behavioral context: partial-update semantics ('Nur die Felder senden, die sich ändern sollen; alles andere bleibt') and the explicit inability to delete. It does not cover error cases or what a rejected update looks like, so not a full 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 tight paragraphs with the core verb and partial-update rule front-loaded, followed by the edge-case routing. The field enumeration slightly restates the schema but stays compact and every sentence carries weight.

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 15-param mutation tool with no output schema, the description supplies the identification keys, the partial-update contract, ownership handling, and the delete limitation. Remaining gap is failure/permission behavior, but the essentials for correct invocation 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 67% with rich field-level descriptions, and the description adds the identification mechanism ('über Tag und die nummer aus session_lesen') plus a full enumeration of the editable fields. It complements rather than merely repeats the schema, though it does not explain the trickier fields (optional, beginnt_um, optional_minuten) 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 precise verb+resource ('Ändert ein einzelnes Modul') and enumerates the mutable fields, letting an agent distinguish it from module_hinzufuegen (adds), modul_verschieben (moves), and session_aendern (edits the session itself). The scope 'einer eigenen Session' further narrows it against 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?

Explicitly names the alternative for the out-of-scope case ('Gehört die Session jemand anderem, nimm zuerst session_kopieren') and states an exclusion ('Löschen kann dieses Werkzeug nicht'). When-to-use and when-to-delegate are both spelled out.

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 mutating, non-idempotent, non-destructive operation. The description adds real behavioral context beyond that: everything following shifts automatically ('Alles Folgende rückt automatisch nach') and concurrent small groups sharing the same 'parallel' name collapse into one parallel block. It does not describe the response or partial-failure behavior.

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

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

Three short paragraphs, purpose front-loaded, no filler. Each sentence carries a distinct constraint (ownership, duration units, auto-shift, parallel grouping).

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 4-parameter mutation tool with no output schema, the description covers the key prerequisites (own session), the cascade side effect, and the parallel-grouping semantics. Missing only return/confirmation behavior, which is minor given the rich schema.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters in depth. The description adds only the minutes-vs-clock-times rule, which the 'minuten'/'von'/'bis' field descriptions already cover, 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 and resource: it appends modules to a day of an existing session ('Hängt Module an einen Tag einer bestehenden Session an'). This is clearly distinct from sibling modul_aendern and modul_verschieben, though those are not named for contrast.

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 when-not plus alternative: 'Nur bei eigenen Sessions; gehört sie jemand anderem, nimm zuerst session_kopieren.' It also steers duration entry (minutes vs clock times), but offers no guidance on choosing between appending and editing/moving existing modules.

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

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

The description discloses key side effects beyond the annotations: nothing is copied or deleted, the same module identity is preserved, both days are re-timed, and all module numbers shift. It also warns that the 'nummer' values become stale and must be refreshed via session_lesen. This is substantive behavioral transparency for a mutating operation.

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

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

Three short paragraphs front-load the core action, then cover side effects and the conditional prerequisite. Each sentence carries distinct information, and there is no filler or repetition of annotation values.

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

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

Despite having no output schema and only false-valued annotations, the description gives the agent everything needed to invoke the tool correctly: target semantics, side effects, stale-number warning, and the foreign-session prerequisite. The instruction to re-read the session compensates for the absent output schema.

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

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

The input schema already documents all five parameters in detail, so the baseline is high. The description adds useful operational context by explaining the renumbering mechanics and reinforcing that 'nach_nummer' is evaluated against the pre-move numbering. It does not add much new per-parameter detail, but it strengthens the critical 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?

The description opens with the specific verb-resource pair 'Verschiebt ein Modul' and defines the allowed targets: within a day or to another day. It further distinguishes the operation from copying or deleting by stating that the same module with all texts and attachments moves. This clearly separates it from siblings like module_hinzufuegen or session_kopieren.

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

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

It provides an explicit routing rule: if the session belongs to someone else, use session_kopieren first. It also gives a concrete after-use instruction to re-read the session with session_lesen before addressing another module. This tells the agent both when the tool is applicable and what to do afterward.

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

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

The description goes beyond annotations by disclosing that notes are private (nobody else sees them), that markings are tied to exact text and silently vanish if the text changes, and that the flow remains untouched. These are critical behaviors not captured by annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and they align without contradiction.

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

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

The description is well-structured and front-loaded: it opens with the core purpose, then gives usage guidance, then color semantics, then the exact-matching caveat, and finally the foreign-session note. Every sentence carries necessary information; there is no fluff or redundancy.

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

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

For a tool with 5 parameters (one a nested array) and no output schema, the description provides all essential context: what the tool does, when to use it, how marks work (colors, exact text, disappearing), and that it's non-destructive. Combined with the rich schema, an agent has everything needed 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the color semantics (yellow=pay attention, pink=open, blue=remember) and the exact-text matching behavior for marks, which goes beyond the schema's brief descriptions. However, it doesn't add much for id, nummer, or tag, which are already well-described in the schema.

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

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

The description states the exact purpose: writing personal notes or marking text in a module, and explicitly distinguishes it from modul_aendern for flow changes. It names the resource (module) and the actions (note, mark) clearly, making it unmistakable from sibling tools.

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

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

It explicitly tells when to use this tool (for reminders that don't alter the flow) and when not (for flow changes, pointing to modul_aendern). It also mentions it works in foreign sessions, giving the agent 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?

With minimal annotations (only readOnlyHint=false, destructiveHint=false), the description carries the behavioral burden and delivers richly: bilden creates TWO tracks immediately, feld switching deletes nothing (texts persist in background), aufloesen lengthens the day by reverting to sequential counting, and the gruppe ID source is specified via session_lesen's 'parallel' field. The repeated 'nothing is deleted' claims are consistent with destructiveHint=false, so no contradiction.

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

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

The description is front-loaded with the core concept and the key scheduling rationale before the bulleted action list. The structure with bolded action names and behavioral consequences is scannable. It is somewhat verbose - the 'Warum es dieses Werkzeug braucht' paragraph runs long - but each sentence contributes either conceptual clarity or a side-effect warning, so it mostly 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 complex tool (8 params, 5 actions, mutation semantics, no output schema), the description covers the full action set, side effects, the source of the gruppe ID, and the required user warning. The only real gaps are the return value (not disclosed, but acceptable for a mutation tool) and explicit differentiation from sibling tools like modul_aendern, which the scheduling rationale partially addresses.

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% - all 8 parameters have descriptions specifying which action each serves (tag for bilden/benennen, nummer for bilden/benennen, gruppe for schiene/feld/aufloesen). The description adds conceptual domain context (what a Schiene is, how groups relate to modules) that enriches understanding, but it doesn't introduce per-parameter semantics beyond the schema. Baseline 3 is appropriate since the schema already carries the burden.

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

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

The description clearly states the verb (setzen/manage), the resource (parallel groups - multiple modules running simultaneously), and enumerates all five actions (bilden, schiene, benennen, feld, aufloesen) with their effects. It explicitly differentiates itself from the naive alternative of creating multiple modules with the same time, making it distinguishable from sibling tools like module_hinzufuegen 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?

The description explains when this tool is needed rather than 'mehrere Module mit derselben Uhrzeit', including the concrete scheduling consequence (5x45min counts as 45min, not 225min). It also tells the agent to warn the user before aufloesen because the day becomes longer. However, it doesn't explicitly name sibling tools as alternatives or state when NOT to use it beyond the implicit scheduling scenario.

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

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

Annotations already mark this as destructive and non-idempotent, but the description adds critical context beyond those flags: the invitation is an irreversible email, cannot be retracted, requires user-side permission that the agent cannot grant, and sending to a guessed address could reach a stranger. This is exactly the behavioral transparency an agent needs.

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

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

The description is front-loaded with the core action, then uses a clearly marked WICHTIG block for critical constraints and closes with a practical 'ask first' rule. Every sentence carries operational value; 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 3-parameter mutation tool with no output schema, the description covers the important operational context: permission requirements, the response behavior on missing permission, irreversibility, and the need to avoid guessing emails. Combined with the full schema coverage and destructive/readOnly annotations, nothing essential is missing for safe invocation.

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

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

Schema description coverage is 100%, and the schema already explains id, email, and rolle in detail, including the meaning of each enum value and the warning not to guess the email. The description repeats the role labels but adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Lädt eine Person per E-Mail zu einer Session ein' with three role options. This clearly distinguishes it from sibling tools like modul_aendern, session_anlegen, or session_kopieren, which target different objects or operations.

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

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

The description gives explicit when-to-use guidance: only when the user has explicitly allowed invitations in Sessionario, and it explains the scope of whom the agent may invite. It also tells the agent what to do when permission is missing — pass along the response and do not retry — and advises asking the user when in doubt.

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, idempotent=true, destructive=false), it discloses the non-obvious side effect that changing start/end retimes the whole schedule while preserving module durations and parallel blocks, and that the caller need not recompute times. It also documents partial-update semantics (send only changed fields), empty-string clearing, and the ownership constraint. This is substantive context the 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?

The purpose and the most important guidance are front-loaded, but the text is long and repeats itself: the retiming cascade ("Alle Module ... rücken geschlossen mit", "Du musst also KEINE Uhrzeit selbst ausrechnen") appears twice near-verbatim, and the display-settings paragraph re-lists fields already enumerated in the first line. Each idea earns its place, but the duplication costs 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 15-parameter mutation tool with no output schema, the description covers the risky areas well: retiming side effects, partial updates, field clearing, ownership preconditions, and the day-count reduction caveat (detailed in the schema). It could say more about what a successful call returns or how validation failures surface, 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 coverage is 93%, so the schema already documents most parameters; the description adds cross-parameter relationships instead of repeating them: beginn_uhrzeit/ende_uhrzeit apply to all days while tageszeiten handles single-day deviations, and the spalten list must be complete rather than partial. It adds real meaning without covering every field (e.g. erster_tag, sprache, art colors are left to the schema).

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

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

The opening sentence names the specific verb and resource ("Ändert die Angaben ZUR Session selbst") and enumerates the editable attributes, so the agent immediately knows the scope. It is explicitly distinguished from modul_aendern/module_hinzufuegen (per-module edits) and from session_anlegen/session_kopieren (creating sessions).

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 concrete trigger phrases ("nenn die Session anders", "die findet doch in Köln statt", "wir fangen eine halbe Stunde früher an"), explicit exclusions (module duration/text/order and fixed per-module times belong to modul_aendern and module_hinzufuegen), and a prerequisite (if the session belongs to someone else, use session_kopieren first). It also warns against creating a duplicate session and explains why.

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, it discloses important behavior: the user becomes owner, Sessionario computes times sequentially from the day start, breaks must be modeled as modules, template-specific `arten` and `spalten` should be carried over, and parallel groups must share the same `parallel` value to avoid inflated timing. These are substantive operational details that materially affect correct invocation.

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

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

The description is front-loaded with the main purpose and trigger phrases, then organized into focused operational warnings about time calculation, templates, and parallel groups. Despite its length, each paragraph addresses a distinct high-value pitfall for this complex creation 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?

Given 12 parameters, nested module objects, and no output schema, the description covers the critical behavioral context needed to create a correct session. It could be slightly more complete by routing agents away from update or module-addition siblings, but the schema itself is very detailed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for tricky parameters: use `minuten` rather than calculating times, use `von`/`bis` when available, use `art="break"` for pauses, and use `arten`/`spalten` for template fidelity. It does not explain every parameter, but the schema already handles the straightforward ones.

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

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

The description states a specific verb and resource: creating a new session for workshops, seminars, or training, optionally filling the full agenda. It uses trigger phrases like "leg mir … an" and "erstelle eine Session", but does not explicitly distinguish this tool from siblings such as `session_aendern` or `module_hinzufuegen`.

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

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

It clearly says when to use the tool through concrete trigger phrases and explains that the whole agenda can be created at once. It lacks explicit when-not-to-use guidance or direct alternatives, such as adding modules later via `module_hinzufuegen`.

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

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

The description discloses behavioral traits beyond the annotations: it states that oversized images are resized rather than rejected, that entfernen removes the image, and that the current state is not visible in session_lesen. These details are not in the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and significantly help the agent anticipate behavior. No contradictions found.

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

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

The description is moderately long but every sentence contributes. It is well-structured: purpose first, then rationale, then parameters, then removal, then a caveat. It is front-loaded with the core action and not excessively verbose given the tool's complexity. Slightly longer than necessary, but justifiably so.

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

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

For a tool with 4 parameters, no output schema, and full schema coverage, the description covers all essential aspects: image format, resizing behavior, mode semantics, removal option, and the critical caveat about not being able to read the current image from session_lesen. An agent has everything needed 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 coverage is 100%, so the baseline is 3. The description adds practical value by explaining that 'bild' accepts both data-URI prefixed and raw Base64, by giving concrete examples for 'modus' (fit vs crop), and by clarifying the auto heuristic (width >1.5:1 treated as logo). This goes beyond the schema's own descriptions, earning a 4.

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 and resource: 'Setzt das Bild, das auf der Kachel und in der Liste vor der Session steht' – it sets the title image for a session tile. It distinguishes itself from siblings like session_aendern (which edits session fields) and session_lesen (which reads), making the purpose unmistakable.

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

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

It provides explicit guidance on when to use the tool (to set a logo or photo) and when not to rely on it (the current image is not in session_lesen, so the agent must ask the user). It also explains mode selection (fit for logos, crop for photos, auto heuristic) and removal via entfernen, covering the main usage decisions.

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 indicate readOnlyHint=false (write) and destructiveHint=false. The description adds meaningful behavior: the copy includes all modules, belongs to the user, and the original remains untouched. This goes beyond annotations and clarifies the non-destructive nature and ownership change. It could have mentioned any side effects like permission checks, but that is minor given the simple scope.

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

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

The description is compact: one sentence for the core purpose and one sentence for usage guidance. It is front-loaded with the action and adds the critical usage trigger without any fluff. Every sentence earns its place, and the structure is easy to parse.

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

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

For a simple tool with 2 parameters, no output schema, and minimal annotations, the description covers purpose, ownership, usage trigger, and effect on the original. Nothing an agent needs to call it correctly is missing. The usage context is particularly well-specified for the write-conflict scenario.

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% for both parameters: 'id' (from sessions_suchen) and 'titel' (default to '(Kopie)'). The description itself adds no extra parameter detail beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the full documentation burden.

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

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

The description clearly states a specific action: 'Macht eine eigene Kopie einer Session - mit allen Modulen' (makes its own copy of a session with all modules). It also specifies ownership transfer, which distinguishes it from read or modify tools. The verb 'kopieren' and the resource 'Session' are unambiguous and differentiate it from siblings like session_anlegen (create) or session_lesen (read).

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?

Explicit when-to-use guidance: 'Nimm das IMMER, wenn ein Schreibversuch meldet, dass die Session jemand anderem gehört' (Always use this when a write attempt reports the session belongs to someone else). It also instructs the agent to inform the user and reassures that the original remains unaltered. No alternatives are mentioned, but the condition is precise and actionable.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description nonetheless adds substantial behavioral context: permission-dependent fields (Trainerhinweise, zusatz, nachbereitung only if the user may edit), attachment structure, block/parallel semantics, and the critical arithmetic rule that parallel tracks run simultaneously and blocks cost the longest track. Also explains why self-summing is wrong and to use dauer_minuten. Far 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?

Front-loaded with the core return shape in the first sentence, then structured paragraphs on attachments, blocks, parallel groups, and arithmetic. Dense but every paragraph earns its place for a rich read tool. Slightly long, but justified by the domain complexity.

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, so the description carries the full burden of explaining the return value, and it does: day/module/attachment/block/parallel fields, permission-gated fields, and the dauer_minuten fallback. An agent has everything needed to call it and interpret the result correctly.

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

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

Schema coverage is 100% and the single id parameter is already documented as coming from sessions_suchen. The description reinforces this provenance. With only one parameter, the baseline is high; the description adds no syntax beyond the schema but does not need to.

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

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

Specific verb (liefert) and resource (eine Session vollständig), with explicit scope: alle Tage, Module mit Uhrzeit und Dauer, Ziel, Inhalt, Material, parallele Kleingruppen. Clearly distinguished from sibling sessions_suchen (which provides the ID) and from the write 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?

Names where the ID comes from (sessions_suchen) and gives a strong re-read guideline: take this tool again after every change before addressing the next module, because module nummer shifts. Lacks explicit when-not-to-use, but the usage context is 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?

Beyond the readOnlyHint annotation, the description discloses the default behavior when no search term is provided (most recently modified) and confirms the output is the IDs needed by session_lesen. This adds meaningful 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 three compact, purposeful sentences: what the tool does, when to use it, and its default behavior. No wasted words and the key guidance is front-loaded.

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

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

For a low-complexity, read-only search tool with zero required parameters, the description covers the trigger conditions, scoping, default behavior, and output purpose. The absence of a return-format description is minor because the tool is clearly a lightweight ID lookup feeding session_lesen.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds only the empty-search default behavior but does not add meaning for 'anzahl' beyond the schema; 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 clearly states the verb 'Findet' and the resource: the user's workshops and seminars in Sessionario. It also differentiates the tool from the sibling session_lesen by explaining that it supplies the IDs that session_lesen needs.

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

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

The description gives explicit trigger phrases ('meiner Session', 'dem Workshop bei X', 'Termin') and instructs the agent to use this tool first. It names session_lesen as the dependent follow-up but does not explicitly exclude other sibling tools.

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