Skip to main content
Glama

Module hinzufügen

module_hinzufuegen

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".

Input Schema

NameRequiredDescriptionDefault
idYesDie ID der Session.
tagNoAn welchen Tag angehängt wird (Vorgabe 1).
moduleYesDie neuen Module, in der Reihenfolge, in der sie laufen sollen.
nach_nummerNoEinfügen NACH diesem Modul (die "nummer" aus session_lesen). Ohne Angabe kommen die Module ans Ende des Tages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / module / items / properties / optional
      Added value: +{
      +  "description": "Ein Modul, das im Plan STEHT, aber keine Zeit kostet - die Reserve, die Übung für den Fall, dass die Gruppe schneller ist.\n\nSchreib „optional\" NICHT in den Titel und nicht in den Inhalt. Das ist ein Schalter, kein Wort: Sessionario zeichnet das Modul dann mit gestrichelter Linie und lässt seine Minuten aus der Tagesrechnung heraus. Ein Modul, das nur im Titel „(optional)\" heißt, verschiebt den ganzen Rest des Tages nach hinten - und der Nutzer sieht erst am Ende, dass sein Tag nicht mehr aufgeht.\n\nDie Dauer gibst du ganz normal in „minuten\" an; sie wird beiseite gelegt und steht wieder da, sobald das Modul eingeplant wird.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources