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.