Sessionario is a workshop and training planner for facilitators. Connect it to your AI and the assistant can read your session, add and rewrite modules, move things around, and let all the times recalculate themselves.
One tool is marked destructive: inviting a person sends an email you cannot recall. Nothing in this server deletes anything.
Scored across 14 tools
Each tool targets a distinct resource and action, and the descriptions go out of their way to contrast the genuinely confusable pairs (block_setzen vs parallelgruppe_setzen, modul_aendern vs session_aendern vs module_hinzufuegen). No two tools appear to do the same thing.
Names follow a mostly predictable snake_case verb_noun pattern (session_anlegen, modul_aendern, notiz_setzen, person_einladen). Minor inconsistency: the noun stem varies between 'modul' (modul_aendern, modul_verschieben) and 'module' (module_hinzufuegen), and verb suffixes are somewhat varied (setzen/aendern/hinzufuegen/verschieben).
At 14 tools the surface is well-scoped for a rich session-planning domain with modules, blocks, parallel groups, notes, attachments, images, and sharing. Each tool earns its place, and none is redundant.
The lifecycle is largely covered: search, read, create, copy, modify session and modules, plus blocks, parallel groups, notes, attachments, images, and invites. The main gap is deletion (sessions, modules, attachments, images are removed only in the app), which is an intentional but real dead end for an agent.
Hängt eine Datei an ein Modul oder an die ganze Session - eine Rollenkarte, einen Beobachtungsbogen, die ausformulierten Prompts eines KI-Rollenspiels, eine Präsentation.
Wofür das da ist: Ein importierter Leitfaden verweist an zehn Stellen auf Dateien, die je mehrere hundert Zeilen lang sind. Die gehören nicht ins Feld „material" - dort machen sie den Ablauf für die Leitung unlesbar. Als Anhang liegen sie an dem Modul, zu dem sie gehören, und der Ablauf bleibt kurz.
Ohne „tag" und „nummer" hängt die Datei an der Session statt an einem Modul. Was schon danebenliegt, steht in session_lesen unter „anhaenge" - sieh dort nach, bevor du dieselbe Datei ein zweites Mal schickst. Höchstens 50 Anhänge je Session und 50 MB je Datei; reicht der Platz des Tarifs nicht, sagt das Werkzeug es im Klartext. Entfernt wird ein Anhang in der App.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| tag | No | Der Tag des Moduls (Vorgabe 1). Zählt nur zusammen mit "nummer". | |
| mime | No | Der MIME-Typ, z. B. "text/markdown" oder "application/pdf". Ohne Angabe: application/octet-stream. | |
| daten | Yes | Der Inhalt der Datei als Base64. Reiner Text geht genauso: als .md oder .txt, aber ebenfalls Base64-kodiert. | |
| nummer | No | Die "nummer" des Moduls aus session_lesen. Fehlt sie, hängt die Datei an der Session. | |
| dateiname | Yes | Wie die Datei heißen soll, mit Endung - "Case_01_Rollenspiel.md". |
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.
Blöcke: mehrere Module NACHEINANDER unter einem gemeinsamen Dach - zum Beispiel ein Input und die Übung dazu, mit einer Überschrift darüber und der Gesamtzeit.
NICHT ZU VERWECHSELN mit parallelgruppe_setzen. Der Unterschied ist die Zeit: • Parallele Gruppe = GLEICHZEITIG. Vier Gruppen zu 40 Minuten sind 40 Minuten im Raum. • Block = NACHEINANDER. Input 30 plus Übung 45 sind 75 Minuten im Raum.
Beides geht zusammen: Ein Block darf parallele Gruppen enthalten. Input 20, dann vier Gruppen zu 40 gleichzeitig, dann Auswertung 15 - der Block dauert dann 75 Minuten, nicht 195.
Die Aktionen: • verbinden - macht aus zwei benachbarten Modulen einen Block. Gehört das obere schon zu einem Block, wächst dieser, statt dass ein zweiter entsteht. • loesen - nimmt EIN Modul aus seinem Block. Es bleibt im Tag und rutscht hinter den Block. Bleibt nur noch EIN Modul im Block, verschwindet das Dach von selbst - ein Block mit einem Modul wäre keiner. • aufloesen - löst den GANZEN Block auf: alle Module stehen wieder für sich, in derselben Reihenfolge. Name, Ziel und Inhalt des Dachs sind damit weg. Gib hier die "nummer" des Dachs an oder die eines Moduls darin.
Zwei BLÖCKE lassen sich mit "verbinden" zusammenlegen: Gib als "nummer" das Dach des oberen und als "mit_nummer" das Dach des unteren an. Die Module des unteren ziehen dann unter das obere Dach, und der Name des unteren fällt weg - sag das dem Nutzer, bevor du es tust, wenn der untere einen Namen hat. Ebenso geht ein einzelnes Modul an einen bestehenden Block: Dach des Blocks und Nummer des Moduls.
Der Titel des Blocks bleibt beim Verbinden LEER. Setz ihn danach mit modul_aendern auf die "nummer" des Dachs - es steht in session_lesen mit "ist_block": true. Gib ihm auch Ziel und Inhalt, wenn der Block eine eigene Klammer braucht; die Texte der Submodule bleiben davon unberührt.
Die Zeit des Dachs ist die Summe seiner Kinder und wird gerechnet - ändere sie nicht mit modul_aendern, sondern die Minuten der einzelnen Submodule.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| tag | No | Der Tag der Module (Vorgabe 1). | |
| aktion | Yes | Was geschehen soll. | |
| nummer | Yes | Die "nummer" aus session_lesen. Bei "verbinden" das OBERE der beiden Module (oder das Dach des oberen Blocks), bei "loesen" das Submodul, das heraus soll, bei "aufloesen" das Dach oder ein Modul darin. | |
| mit_nummer | No | Nur für "verbinden": die "nummer" des Moduls darunter - oder das Dach des Blocks darunter, wenn zwei Blöcke zusammengelegt werden sollen. Ohne Angabe wird das direkt folgende genommen. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is otherwise extremely transparent (what dissolves, that a one-module block self-destructs, that title stays empty, that time is computed), but it explicitly states that with 'aufloesen' the roof's Name, Ziel und Inhalt 'sind damit weg' — irreversible data loss — while the annotation declares destructiveHint=false. That conflict directly undermines the annotation's safety signal.
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 block-vs-parallel distinction and bulleted per-action semantics; long but well-structured for a tool with three operations. A few sentences (e.g. re-explaining the parallel example) are somewhat redundant but earn most of their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all three actions, edge cases (single-module block), follow-up steps (set title via modul_aendern, inspect via session_lesen), and the computed-time caveat. No output schema exists, but the behavioral contract is fully described.
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 value beyond the schema: it explains which 'nummer' to supply per action and the semantics of merging two blocks vs. attaching a single module via 'mit_nummer', plus the naming consequence of the lower block losing its name.
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 (Module zu einem Block verbinden) with the three operations named inline, and explicitly disambiguates from the sibling parallelgruppe_setzen. An agent can identify this tool and its 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?
It explicitly contrasts this tool with parallelgruppe_setzen (simultaneous vs. sequential time), explains that the two can combine, and gives concrete when-to-use scenario for every action (verbinden/loesen/aufloesen), including the two-block merge case. Alternatives and exclusions are fully named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ändert ein einzelnes Modul einer eigenen Session - Titel, Dauer, feste Uhrzeit, Ziel, Inhalt, Material, Trainerhinweis, Zusatz, Nachbereitung oder Art. Angegeben wird es über Tag und die "nummer" aus session_lesen. Nur die Felder senden, die sich ändern sollen; alles andere bleibt, wie es ist.
Gehört die Session jemand anderem, nimm zuerst session_kopieren. Löschen kann dieses Werkzeug nicht - das macht der Nutzer in der App.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| art | No | Wozu der Block da ist - nicht die Methode, nicht das Medium. orientation=Einstieg & Orientierung, connection=Verbindung & Aktivierung, input=Impuls & Verstehen, exploration=Erkunden & Analysieren, ideation=Ideen & Gestalten, decision=Bewerten & Entscheiden, practice=Anwenden & Erproben, reflection=Reflexion & Transfer, closing=Abschluss & Feedback, break=Pause, offprogramme=Drumherum (Anreise, Abendessen - zählt nicht zur Workshopzeit). | |
| tag | No | Der Tag (Vorgabe 1). | |
| ziel | No | ||
| titel | No | ||
| inhalt | No | ||
| nummer | Yes | Die "nummer" des Moduls aus session_lesen. | |
| zusatz | No | Die sechste Spalte („Zusatz") - lange Prompts, Kartentexte, Beobachtungsbögen. Leerer String löscht sie. | |
| minuten | No | Neue Dauer. Alles Folgende rückt nach. | |
| material | No | ||
| beginnt_um | No | Eine FESTE Uhrzeit für dieses Modul, z. B. "14:00" - für Dinge, die zu einer verabredeten Zeit stattfinden: der Gastredner, das Mittagessen, die Schaltung zur Zentrale. Das Modul bekommt damit ein Schloss: Es bleibt auf seiner Zeit, auch wenn davor etwas länger dauert, und die Kette läuft ab seinem Ende weiter. Leerer String nimmt das Schloss wieder weg - dann hängt das Modul wie alle anderen in der Kette. Für alles Übrige gilt: nur "minuten" angeben, Sessionario rechnet. | |
| nachbereitung | No | Die siebte Spalte („Nachbereitung") - Transfer und Aufgaben nach dem Modul. Leerer String löscht sie. | |
| trainerhinweis | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, non-destructive), the description discloses partial-update semantics ("Nur die Felder senden, die sich ändern sollen; alles andere bleibt"), cascade effects of duration changes (via schema for minuten: "Alles Folgende rückt nach"), fixed-time locking semantics for beginnt_um, and that empty strings delete zusatz/nachbereitung. This adds substantial behavioral context 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 two short paragraphs, front-loaded with the core purpose, then ownership and deletion boundaries. Every sentence provides distinct information: what changes, how to identify, partial-update semantics, when to copy instead, and what cannot be done. 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, the description covers identification, partial updates, ownership constraints, deletion boundary, and key behavioral side effects (time locking, shifting chain). It falls just short of full completeness because a few parameters (ziel, titel, inhalt, material, trainerhinweis) have no description in either schema or main text, forcing the agent to guess from names. Error/return behavior is also not addressed, but annotations mitigate some 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?
The description clarifies how to identify the target module (Tag + nummer from session_lesen) and the partial-update principle, which adds meaning beyond the schema. However, schema coverage is only 62%, and the description does not compensate for undocumented parameters like ziel, titel, inhalt, material, or trainerhinweis – it merely lists their names. The schema descriptions for some params (art, beginnt_um, minuten, zusatz, nachbereitung) already carry the load; the description adds modest value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Ändert ein einzelnes Modul einer eigenen Session" and enumerates the exact fields (Titel, Dauer, feste Uhrzeit, etc.). It also explicitly disclaims deletion ("Löschen kann dieses Werkzeug nicht"), which distinguishes it from other mutation tools like module_hinzufuegen or modul_verschieben.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-not: "Gehört die Session jemand anderem, nimm zuerst session_kopieren", naming the alternative tool and the condition that triggers it. It also states a boundary (no deletion, user does it in the app), and specifies how to address the module (via Tag and nummer from session_lesen).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hängt Module an einen Tag einer bestehenden Session an. Nur bei eigenen Sessions; gehört sie jemand anderem, nimm zuerst session_kopieren.
Auch hier: nur Dauer in Minuten, keine Uhrzeiten. Alles Folgende rückt automatisch nach.
Gleichzeitig laufende Kleingruppen bekommen alle dasselbe "parallel".
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| tag | No | An welchen Tag angehängt wird (Vorgabe 1). | |
| module | Yes | Die neuen Module, in der Reihenfolge, in der sie laufen sollen. | |
| nach_nummer | No | Einfügen NACH diesem Modul (die "nummer" aus session_lesen). Ohne Angabe kommen die Module ans Ende des Tages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context: modules are appended to a day, subsequent content shifts automatically, parallel groups receive the same 'parallel' label, and only durations in minutes are used (no times). It doesn't fully describe all side effects (e.g., what happens to existing modules after insertion), but it 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?
The description is compact and front-loaded with the core action and the most important constraint (own sessions only). The parallel-group explanation is somewhat long but necessary for correct usage. Every sentence earns its place, though the parallel explanation could be slightly trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description covers the key behavioral aspects: ownership prerequisite, time handling, parallel groups, and insertion position. It doesn't explicitly state what the response looks like or whether the operation is reversible, but the schema and annotations cover the parameter space well. The main gap is lack of return-value info, which is minor for an append operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters thoroughly. The description adds important semantic guidance: 'nur Dauer in Minuten, keine Uhrzeiten' clarifies the minuten parameter, and the parallel field explanation is extensive. It also clarifies that 'nach_nummer' is optional and defaults to end of day. This is above the baseline 3 because the description adds meaningful usage context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Hängt ... an') and resource ('Module an einen Tag einer bestehenden Session'), and clearly distinguishes from siblings by naming session_kopieren for foreign sessions and anhang_hinzufuegen for file attachments. It also clarifies the operation is for appending modules, not modifying or moving 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?
Explicitly says when to use this tool (own sessions) and when not (foreign sessions → session_kopieren first). It also gives a clear alternative for whole files (anhang_hinzufuegen) and explains the parallel-group usage rule. This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verschiebt ein Modul an eine andere Stelle - innerhalb eines Tages oder auf einen anderen Tag. Nichts wird kopiert und nichts gelöscht; es ist dasselbe Modul mit allen Texten und Anhängen, nur woanders.
Beide Tage werden danach neu getaktet: Am alten Tag rücken die folgenden Module auf, am neuen rücken sie nach. Die "nummer" aller Module verschiebt sich dadurch - lies die Session mit session_lesen neu, bevor du das nächste Modul ansprichst.
Gehört die Session jemand anderem, nimm zuerst session_kopieren.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| tag | No | Der Tag, an dem das Modul JETZT steht (Vorgabe 1). | |
| nummer | Yes | Die "nummer" des Moduls aus session_lesen. | |
| nach_tag | No | Der Tag, auf den es soll. Fehlt er, bleibt es an seinem Tag. | |
| nach_nummer | No | Die Stelle am Zieltag: 1 heißt „ganz nach vorne". Fehlt die Angabe, kommt das Modul ans Ende des Zieltages. Gezählt wird in den Nummern, die VOR dem Verschieben gelten. |
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.
Schreibt eine persönliche Notiz an ein Modul oder markiert eine Stelle im Text - für den Nutzer allein. NIEMAND SONST SIEHT DAS, auch nicht in derselben Session. Nimm das für alles, was eine Erinnerung ist und keine Änderung am Ablauf: „hier bin ich letztes Mal aus der Zeit gelaufen", „Flipchart vorbereiten", „diesen Absatz kürzen". Der Ablauf selbst bleibt unangetastet - wer ihn ändern will, nimmt modul_aendern.
Markierungen tragen eine Farbe mit fester Bedeutung: gelb = aufpassen, rosa = offen/noch zu klären, blau = merken. Markiert wird über den TEXT, den du anstreichen willst - er muss genau so im Feld stehen. Findet er sich später nicht mehr, weil jemand das Modul umgeschrieben hat, verschwindet die Markierung still.
Das geht auch bei fremden Sessions, an denen der Nutzer beteiligt ist: Eine Notiz ändert dort nichts, sie kommt hinzu.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| tag | No | Der Tag (Vorgabe 1). | |
| notiz | No | Die persönliche Notiz. Leerer String löscht sie. Weglassen lässt sie unberührt. | |
| nummer | Yes | Die "nummer" des Moduls aus session_lesen. | |
| markieren | No | Stellen, die angestrichen werden sollen. Ersetzt die bisherigen Markierungen dieses Moduls - wer eine dazunehmen will, schickt die alten mit. Leere Liste entfernt alle. |
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.
Parallele Gruppen: mehrere Module zur SELBEN Zeit - fünf Kleingruppen, dieselbe Stunde, verschiedene Themen.
Warum es dieses Werkzeug braucht und nicht mehrere Module mit derselben Uhrzeit: Fünf Kleingruppen zu 45 Minuten sind 45 Minuten im Tagesablauf, nicht 225. Ohne echte Gruppe rechnet Sessionario stur weiter und der Tag endet Stunden zu spät.
Die Aktionen: • bilden - macht aus einem Modul eine Gruppe. Es entstehen SOFORT zwei Schienen; eine Schiene allein wäre keine Gruppe. • schiene - eine weitere Gruppe in denselben Zeitraum. • benennen - der Name einer Schiene („Marktanalyse-Team" statt „Gruppe 2"). • feld - legt fest, ob ein Feld für ALLE Gruppen gilt (steht dann oben über dem Block) oder jede Gruppe ihr eigenes hat. Umschalten löscht nichts: Die eigenen Texte der Schienen bleiben im Hintergrund und sind wieder da, wenn das Feld zurück auf „separat" geht. • aufloesen - wieder einzelne Module untereinander. Nichts wird gelöscht, aber der Tag wird dadurch LÄNGER, weil die Zeiten wieder hintereinander zählen. Sag das dem Nutzer, bevor du es tust.
Die "gruppe" bekommst du aus session_lesen: Jedes Modul einer Gruppe trägt dort ein Feld "parallel" mit der Gruppen-ID und dem Schienennamen.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| tag | No | Der Tag des Moduls - für "bilden" und "benennen" (Vorgabe 1). | |
| feld | No | Welches Feld - für "feld". title=Titel, goal=Ziel, content=Inhalt, trainer_notes=Trainerhinweise, materials=Materialien. | |
| name | No | Der neue Schienenname - für "benennen". | |
| aktion | Yes | Was geschehen soll. | |
| gruppe | No | Die Gruppen-ID aus session_lesen - für "schiene", "feld" und "aufloesen". | |
| nummer | No | Die "nummer" des Moduls aus session_lesen - für "bilden" (welches Modul wird zur Gruppe) und "benennen" (welche Schiene bekommt den Namen). | |
| gemeinsam | No | true = das Feld gilt für alle Gruppen, false = jede Gruppe hat ihr eigenes. Für "feld". |
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.
Lädt eine Person per E-Mail zu einer Session ein - mit einer Rolle: ansehen, kommentieren oder mitarbeiten.
WICHTIG: Das geht nur, wenn der Nutzer es in Sessionario ausdrücklich erlaubt hat, und er entscheidet dabei auch, WEN du einladen darfst - nur seine Freundesliste, dazu seine Kontakte, oder jede Adresse. Fehlt die Erlaubnis, bekommst du eine Antwort, die das sagt. Gib sie weiter, statt es noch einmal zu versuchen: Du kannst die Erlaubnis nicht selbst erteilen, und er muss dazu in die App.
Frag im Zweifel vorher nach. Eine Einladung ist eine E-Mail an einen anderen Menschen; sie lässt sich nicht zurücknehmen, auch wenn der Zugang danach entzogen wird.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| Yes | Die E-Mail-Adresse der Person. Rate sie nicht - frag den Nutzer, wenn du sie nicht sicher weißt. Eine Einladung an eine falsche Adresse geht an einen Fremden. | ||
| rolle | Yes | view=nur ansehen, comment=kommentieren, edit=mitarbeiten. Im Zweifel view - mehr Rechte gibt der Nutzer später mit einem Klick, weniger kostet ein Gespräch. |
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.
Ändert die Angaben ZUR Session selbst - Titel, Kunde, Ort, Datum, Sprache, Tageszählung. Nicht den Ablauf; dafür gibt es modul_aendern und module_hinzufuegen.
Nimm das bei "nenn die Session anders", "der Kunde heißt jetzt …", "nimm den Kundennamen raus", "die findet doch in Köln statt", "verschieb sie auf den 3.".
WICHTIG: Leg dafür KEINE neue Session an. Eine zweite Session mit fast demselben Inhalt ist für den Nutzer kein Ergebnis, sondern Aufräumarbeit - löschen kann er nur selbst in der App.
Ein Feld LEEREN: leeren String senden. "kunde": "" entfernt den Kundennamen. Nur die Felder senden, die sich ändern sollen; alles andere bleibt.
Gehört die Session jemand anderem, nimm zuerst session_kopieren.
Auch die ANSICHT gehört hierher: Zeitformat (12 oder 24 Stunden), Zeitzone, Spaltennamen, Modularten und ihre Farben, Anzahl der Tage. Nimm das bei „zeig mir das in AM/PM", „die Session ist in New York", „mach die Pausen grau" oder „wir brauchen noch einen dritten Tag".
ZEITEN: "beginn_uhrzeit" und "ende_uhrzeit" gelten für ALLE Tage. Soll ein einzelner Tag anders laufen ("Tag 2 fangen wir erst um 9:30 an"), nimm "tageszeiten". Der Ablauf wird danach automatisch neu getaktet: Die Module behalten ihre Dauer und rücken geschlossen mit. Rechne die Uhrzeiten also nicht selbst aus - sag nur, wann der Tag beginnt.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| ort | No | Ort oder „online". Leerer String entfernt den Eintrag. | |
| tage | No | Anzahl der Tage. Nach oben ist es harmlos: leere Tage stehen bereit und lassen sich vorplanen. Nach unten verschwinden die Module der wegfallenden Tage NICHT - sie sind nur nicht mehr zu sehen, bis die Zahl wieder reicht. Frag den Nutzer, bevor du verkleinerst. | |
| arten | No | Die Modularten mit ihren Farben - die farbigen Gruppen im Ablauf. Nimm das bei „mach die Pausen blau" oder wenn eine Vorlage eigene Gruppen hat. ACHTUNG: Die Module zeigen über "art" auf den "schluessel". Wer einen Schlüssel wegnimmt, den Module benutzen, färbt sie unbeabsichtigt um - lies die Session vorher mit session_lesen und lass die benutzten Schlüssel stehen. | |
| kunde | No | Auftraggeber oder Firma. Leerer String entfernt den Eintrag. | |
| titel | No | Neuer Titel. Mindestens 3 Zeichen. | |
| beginnt | No | Erster Tag als JJJJ-MM-TT. Leerer String entfernt das Datum. | |
| spalten | No | Die Spaltennamen im Ablauf, in genau dieser Reihenfolge: Übersicht, Ziel, Inhalt, Trainerhinweise, Materialien, Zusatz, Nachbereitung. Alle sieben nennen - eine halbe Liste wäre schlimmer als keine, weil dann die Hälfte der Spalten anders heißt als die andere. | |
| sprache | No | ||
| zeitzone | No | Die Zeitzone der Session als IANA-Name, etwa "Europe/Berlin" oder "America/New_York". Dafür, dass die Uhrzeiten im Ablauf die des Veranstaltungsorts sind und nicht die des Rechners. Leerer String nimmt die Angabe wieder heraus. | |
| erster_tag | No | Welche Nummer der erste Tag trägt - 1 (Vorgabe) oder 0 für Vorlagen mit „Day 0". | |
| zeitformat | No | Ob die Uhrzeiten als 09:00 oder als 9:00 AM angezeigt werden. Nimm das bei „zeig mir das in AM/PM" oder „mach 24 Stunden". Es ist reine ANZEIGE - die gespeicherten Zeiten ändern sich nicht. | |
| tageszeiten | No | Einzelne Tage abweichend. Nur die Tage nennen, die anders laufen als der Rest. | |
| ende_uhrzeit | No | Tagesende für alle Tage, z. B. "17:00". Das Ende ist die Ziellinie im Ablauf - es kürzt kein Modul, sondern zeigt, ob der Tag passt. | |
| beginn_uhrzeit | No | Tagesbeginn für alle Tage, z. B. "09:00". Der Ablauf rückt geschlossen mit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining several behavioral nuances: it warns that a second session with almost the same content is not a result but cleanup work, and that the user can only delete it themselves. It explains the side effects of changing 'tage': shrinking days does NOT delete modules, they are just hidden. It also clarifies that 'beginn_uhrzeit' and 'ende_uhrzeit' apply to all days and that the schedule is automatically re-timed, so the agent should not compute times itself. This adds significant transparency 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?
The description is relatively long but well-structured, with clear paragraphs separating the different kinds of changes (core session data, view settings, and times). It uses bold headers like 'WICHTIG' and 'ZEITEN' to draw attention to key points, and the alternative tool names are mentioned in context. It is efficient, though a bit verbose, but every sentence serves a purpose, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, several with interdependent effects like 'tage' and 'arten'), the description is remarkably complete. It covers the main use cases, pitfalls (like not deleting used 'schluessel' in 'arten'), and the distinction between global and per-day times. It even advises reading the session first with session_lesen before modifying 'arten'. With no output schema, the description provides all necessary guidance to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has a high coverage (93%) with detailed descriptions for parameters like 'tage', 'arten', 'spalten', 'zeitzone', 'zeitformat', and 'tageszeiten'. The description itself does not add much parameter-specific information, but it does provide context for 'beginn_uhrzeit' and 'ende_uhrzeit' by explaining they apply to all days. Since the schema is so thorough, a baseline of 3 is appropriate, with no need for the description to duplicate details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Ändert, changes) and the resource (Session itself), and enumerates the specific attributes that can be changed (Titel, Kunde, Ort, Datum, Sprache, Tageszählung), plus the view-related attributes. It explicitly distinguishes itself from sibling tools like modul_aendern and module_hinzufuegen by saying 'Nicht den Ablauf; dafür gibt es modul_aendern und module_hinzufuegen.' This makes its 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?
The description provides explicit when-to-use guidance with concrete example phrases ('nenn die Session anders', 'der Kunde heißt jetzt …', etc.) for both core and view-related changes. It also states when NOT to use it: 'Gehört die Session jemand anderem, nimm zuerst session_kopieren', and for single-day time changes, it directs to 'tageszeiten'. It even warns against creating a new session instead of using this tool, and warns to ask the user before shrinking the number of days, which is clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legt eine neue Session an (Workshop, Seminar, Training) und füllt auf Wunsch gleich den ganzen Ablauf. Der Nutzer wird Besitzer. Nimm das bei "leg mir … an", "plane einen Workshop", "erstelle eine Session".
WICHTIG: Rechne die Uhrzeiten NICHT selbst aus. Gib je Modul nur die Dauer in Minuten an - Sessionario setzt die Uhrzeiten lückenlos hintereinander, ab dem Tagesbeginn. Das ist zuverlässiger als jede Rechnung im Kopf und bleibt richtig, wenn der Nutzer später etwas einschiebt. Pausen gehören als eigene Module in den Ablauf, mit art="break".
Kommt der Ablauf aus einer Vorlage (SessionLab, ein Trainer-Macro, ein Leitfaden) und hat die eigene Farbgruppen oder eigene Spaltennamen, dann übernimm sie mit "arten" und "spalten". Der Nutzer erkennt seine Vorlage sonst nicht wieder.
Laufen mehrere Kleingruppen GLEICHZEITIG, nimm bei allen dasselbe "parallel" - sonst zählt Sessionario ihre Zeiten hintereinander und der Tag wird zu lang.
| Name | Required | Description | Default |
|---|---|---|---|
| ort | No | Ort oder „online". | |
| tage | No | Anzahl der Tage (Vorgabe 1). | |
| arten | No | Eigene Modularten statt der eingebauten elf - die farbigen Gruppen der Vorlage. Nur angeben, wenn die Vorlage eine eigene Legende hat. Die Module zeigen dann über "art" auf den "schluessel". | |
| kunde | No | Auftraggeber oder Firma, falls genannt. | |
| titel | Yes | Der Titel der Session. | |
| module | No | Der Ablauf. Darf leer bleiben - dann entsteht eine leere Session. | |
| beginnt | No | Erster Tag als JJJJ-MM-TT. Weglassen, wenn kein Termin feststeht. | |
| spalten | No | Die Spaltennamen im Ablauf, in genau dieser Reihenfolge: Übersicht, Ziel, Inhalt, Trainerhinweise, Materialien, Zusatz, Nachbereitung. Nur angeben, wenn die Vorlage eigene Bezeichnungen hat - dann alle sieben nennen. Beispiel aus einem SessionLab-Macro: ["Overview","Framing & Objectives","Process & Facilitation","Pre-Work & App","Logistics & Slides","Extras","Follow-up"]. | |
| sprache | No | Sprache der Session. Vorgabe: die des Nutzers. | |
| erster_tag | No | Welche Nummer der erste Tag trägt. Vorgabe 1. Nimm 0, wenn die Vorlage einen „Day 0" kennt - Anreise, Aufbau, Delivery-Team am Vorabend. Die Zählung verschiebt sich dann für alle Tage: aus Tag 1, 2, 3 wird Tag 0, 1, 2. | |
| ende_uhrzeit | No | Tagesende, z. B. "17:00". Vorgabe 17:00. | |
| beginn_uhrzeit | No | Tagesbeginn, z. B. "09:00". Vorgabe 09:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no readOnly, no idempotency, no open-world), so the description carries the full burden. It discloses multiple behavioral traits: the user becomes owner ('Der Nutzer wird Besitzer'), the server auto-computes contiguous times from day start, parallel groups share time instead of summing, and the warning not to calculate times manually. This is rich context well beyond the uninformative annotations. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every paragraph is functional — no filler. It front-loads the trigger phrases and the critical time-computation warning before the template and parallel handling. For a 12-parameter tool with tricky timing and grouping behavior, the length is justified. It could be slightly tightened but 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?
The tool is complex (12 params, nested modules) with no output schema and uninformative annotations, so the description must do heavy lifting. It covers the hard parts well: time computation, template fidelity, parallel groups, ownership. The only gap is the return value/response of the creation call, which is never mentioned. Still, for the agent's decision to call it correctly, the description is substantially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds genuine supplementary value: guidance to use von/bis from templates instead of calculating durations, using art='break' for pauses, carrying over arten/spalten for template fidelity, and the same 'parallel' name for simultaneous groups. These instructions go beyond the schema's property descriptions and help an agent use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Legt eine neue Session an') with the domain scope (Workshop, Seminar, Training). It clearly distinguishes from siblings by being the creation operation — siblings like session_aendern, modul_aendern, session_lesen are mutations or reads on existing sessions. The trigger phrases ('leg mir … an', 'plane einen Workshop', 'erstelle eine Session') make 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?
The description gives explicit trigger phrases telling the agent when to invoke this tool ('Nimm das bei...'). It provides clear usage context. It doesn't explicitly name alternatives or exclusion cases, but the creation-vs-modification distinction against siblings is implied strongly enough, and the trigger phrases are actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Setzt das Bild, das auf der Kachel und in der Liste vor der Session steht - ein Kundenlogo, ein Motiv zum Thema, eine Skizze.
Wofür das da ist: Wer zwanzig Sessions hat, sucht in einer Liste aus Text. Ein Logo findet das Auge schneller als jede Überschrift - und bei vier Durchgängen desselben Trainings ist es oft das einzige, was sie unterscheidet.
Schick das Bild als „bild" in Base64 (mit oder ohne "data:image/..."-Vorspann). PNG, JPEG oder WebP. Zu große Bilder werden verkleinert, nicht abgewiesen - du musst nichts ausrechnen.
Ein LOGO wird mit "modus": "fit" ganz gezeigt, mit Luft am Rand - sonst schneidet die Kachel dem Schriftzug die Seiten ab. Ein Foto füllt mit "modus": "crop" besser. Lässt du es weg, entscheidet die Form: breiter als 1,5:1 gilt als Logo.
Mit „entfernen": true nimmst du das Bild wieder weg. Was gerade gesetzt ist, steht nicht in session_lesen - frag den Nutzer, wenn du es wissen musst.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID der Session. | |
| bild | No | Das Bild in Base64. Mit "data:image/png;base64,…" davor oder ohne - beides geht. | |
| modus | No | "fit" zeigt das GANZE Bild mit etwas Luft am Rand - so gehören Logos hin. "crop" füllt die Kachel und schneidet ab - für Fotos. Ohne Angabe: "auto", das entscheidet nach dem Seitenverhältnis (breiter als 1,5:1 gilt als Logo). | |
| entfernen | No | true nimmt das Titelbild weg. Dann braucht es kein "bild". |
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.
Macht eine eigene Kopie einer Session - mit allen Modulen. Die Kopie gehört dem Nutzer, er darf sie also ändern.
Nimm das IMMER, wenn ein Schreibversuch meldet, dass die Session jemand anderem gehört. Sage dem Nutzer dann, dass du mit einer Kopie weiterarbeitest - das Original der Kollegin bleibt unberührt.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID aus sessions_suchen. | |
| titel | No | Titel der Kopie. Ohne Angabe der alte Titel mit dem Zusatz „(Kopie)". |
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.
Liefert eine Session vollständig: alle Tage, Module mit Uhrzeit und Dauer, Ziel, Inhalt, Material und - falls vorhanden - parallel laufende Kleingruppen. Die ID kommt aus sessions_suchen. Trainerhinweise, „zusatz" und „nachbereitung" sind nur enthalten, wenn der Nutzer die Session bearbeiten darf.
Unter „anhaenge" stehen die Dateien - Name und Größe, nicht der Inhalt. Je Modul die seinen, oben im Kopf die der ganzen Session. Heruntergeladen wird in der App; hinzufügen kannst du mit anhang_hinzufuegen.
Gehört ein Modul zu einem BLOCK (mehrere Module unter einem Dach), trägt es ein Feld "block" mit der Kennung des Dachs. Das Dach selbst trägt "ist_block": true und seine "kennung". Die Zeit des Dachs ist die Summe seiner Kinder - ändere sie nicht direkt, sondern die der Kinder. Läuft ein Modul parallel zu anderen, trägt es ein Feld "parallel": "gruppe" ist die Gruppen-ID (die brauchst du für das Werkzeug parallelgruppe), "schiene" der Name dieser einen Gruppe, "schienen" die Zahl der gleichzeitig laufenden, "gemeinsam" die Felder, die für alle gelten und deshalb oben über dem Block stehen.
WICHTIG beim Rechnen: Parallele Schienen laufen GLEICHZEITIG. Vier Kleingruppen zu 40 Minuten kosten 40 Minuten, nicht 160. Ein Block kostet immer so lange, wie seine LÄNGSTE Schiene dauert - zähle die "minuten" derselben "gruppe" also nie zusammen. Die fertige Tagessumme steht ohnehin bei jedem Tag unter "dauer_minuten"; nimm die, statt selbst zu addieren. Passt eine Summe nicht zum Tagesrahmen, ist das fast immer der Grund.
Nimm dieses Werkzeug auch NACH jeder Änderung noch einmal, bevor du das nächste Modul ansprichst: Die "nummer" der Module verschiebt sich beim Einfügen, Verschieben und Auflösen von Gruppen.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Die ID aus sessions_suchen. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/openWorldHint; the description adds substantial behavior beyond that: trainer notes, 'zusatz' and 'nachbereitung' appear only if the user may edit the session, attachments expose name/size but not content, and it explains block/parallel field semantics plus the recomputation pitfalls.
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 return-value summary, then moves to conditional fields, attachments, and block/parallel arithmetic. It is long, but nearly every sentence conveys domain semantics the agent cannot infer; only the arithmetic aside is marginally redundant since 'dauer_minuten' already exists per day.
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, so the description must document the return shape, and it does so thoroughly (top-level fields, per-module fields, block and parallel sub-structures, conditional fields). An agent has everything needed to call it and interpret the response.
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 there is a single 'id' parameter, so the schema already carries the parameter. The description still adds provenance ('Die ID kommt aus sessions_suchen'), which is useful but not deep syntax detail, so slightly above the 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 (return/read) and resource (a full session), then enumerates what 'fully' means: all days, modules with time/duration, goal, content, material, and parallel subgroups. This clearly separates it from the sibling sessions_suchen, which only finds 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?
Gives explicit routing ('Die ID kommt aus sessions_suchen'), names the alternative for a related task ('hinzufügen kannst du mit anhang_hinzufuegen'), and states a non-obvious re-invocation rule: call it again after every change before touching the next module because module 'nummer' shifts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Findet die Workshops und Seminare des Nutzers in Sessionario. Nimm dieses Werkzeug immer zuerst, wenn der Nutzer von "meiner Session", "dem Workshop bei X" oder einem Termin spricht - es liefert die IDs, die session_lesen braucht. Ohne Suchbegriff kommen die zuletzt geänderten.
| Name | Required | Description | Default |
|---|---|---|---|
| suche | No | Teil des Titels, des Kundennamens oder des Ortes. Leer lassen für die neuesten. | |
| anzahl | No | Höchstens so viele Treffer (Vorgabe 20). |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
block_setzen3 fields changedInput schema / properties / aktion / enumPrevious value: -[
- "verbinden",
- "loesen"
-]New value: +[
+ "verbinden",
+ "loesen",
+ "aufloesen"
+]Input schema / properties / mit_nummer / descriptionPrevious value: -"Nur für \"verbinden\": die \"nummer\" des Moduls darunter. Ohne Angabe wird das direkt folgende genommen."New value: +"Nur für \"verbinden\": die \"nummer\" des Moduls darunter - oder das Dach des Blocks darunter, wenn zwei Blöcke zusammengelegt werden sollen. Ohne Angabe wird das direkt folgende genommen."Input schema / properties / nummer / descriptionPrevious value: -"Die \"nummer\" aus session_lesen. Bei \"verbinden\" das OBERE der beiden Module, bei \"loesen\" das Submodul, das heraus soll."New value: +"Die \"nummer\" aus session_lesen. Bei \"verbinden\" das OBERE der beiden Module (oder das Dach des oberen Blocks), bei \"loesen\" das Submodul, das heraus soll, bei \"aufloesen\" das Dach oder ein Modul darin."block_setzenDesign workshops from chat: 750+ facilitation methods, timed agendas, worksheets, slide decks.
Meeting agenda timer for AI assistants: build agendas in chat, share a live synced countdown.
AI planner: your calendars, to-dos, goals and booking links. Changes wait for your yes.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Add one secure layer between your agents and this server.
