Skip to main content
Glama

Session Management

manage_session
Destructive

Recap archived play sessions, tune session verbosity, reorder briefing sections, and search available tools for RPG play.

Instructions

Manage play-facing session controls: recap, verbosity, briefing_order, and tool discovery, distinct from story content and Novel lifecycle. recap accepts an archived session_id, GM-only gm_notes, and an optional compression tier; gm_notes are never returned to a non-GM badge. discover searches names, descriptions, and titles, and detail schema requires query. verbosity is session-scoped; briefing_order persists to the Novel and requires the GM or Editor badge. recap and discover are read-only; a setting is restored by setting it again (no undo snapshot is taken). Use when: recapping play, tuning output verbosity, reordering the briefing, or finding a tool. Do NOT use when: health, audit compaction, event-log, or category operations — use manage_diagnostics; recording story content — use manage_story (action: record).

Input Schema

NameRequiredDescriptionDefault
modeNonormal or terse (verbosity).
tierNoCompression tier to assemble (recap; REQ-592).
queryNoOptional search term matched against tool name, description, and title (discover).
actionYesrecap, verbosity, briefing_order, compress (non-mutating audit summary prompt), compact (GM-only irreversible audit-log compaction), health, context_report (per-section token ledger), subscribe, discover (list/search tools), category (reassign a tool's category), event (append an observation), history (read the event log), verify (compare live state to recorded hashes), replay (read-only event-log inspection), visibility_check (scan a draft for GM-only disclosure), or visibility_audit (recent visibility decisions).
detailNodiscover response detail: summary (default) or schema (live input schemas for the matches; requires query; REQ-609).
gm_notesNoGM-only free-text notes returned only to the Game Master badge (recap).
sectionsNoOrdered list of briefing sections (briefing_order).
session_idNoArchived session id to include in recap (recap).
budget_tokensNoPositive token budget for tier assembly (recap; REQ-592) or for ledger packing (context_report; REQ-610).

Output Schema

NameRequiredDescriptionDefault
textNoHuman-readable text envelope mirroring the structured result (REQ-001, REQ-548a).
statusYesMachine-readable result status: OK, NEED_INPUT, WARNING, PARTIAL, or an error category (REQ-002, REQ-548c).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv2026.10.13
    • changedInput schema / properties / action / description
      Previous value: -"recap, verbosity, briefing_order, compress (non-mutating audit summary prompt), compact (GM-only irreversible audit-log compaction), health, subscribe, discover (list/search tools), category (reassign a tool's category), event (append an observation), or history (read the event log)."New value: +"recap, verbosity, briefing_order, compress (non-mutating audit summary prompt), compact (GM-only irreversible audit-log compaction), health, context_report (per-section token ledger), subscribe, discover (list/search tools), category (reassign a tool's category), event (append an observation), history (read the event log), verify (compare live state to recorded hashes), replay (read-only event-log inspection), visibility_check (scan a draft for GM-only disclosure), or visibility_audit (recent visibility decisions)."
    • addedInput schema / properties / budget_tokens
      Added value: +{
      +  "description": "Positive token budget for tier assembly (recap; REQ-592) or for ledger packing (context_report; REQ-610).",
      +  "type": "number"
      +}
    • removedInput schema / properties / category
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "description": "New category label, or null/empty to restore the default (category)."
      -}
    • addedInput schema / properties / detail
      Added value: +{
      +  "description": "discover response detail: summary (default) or schema (live input schemas for the matches; requires query; REQ-609).",
      +  "enum": [
      +    "summary",
      +    "schema"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / properties / include_superseded
      Removed value: -{
      -  "description": "Include superseded events (history; default true).",
      -  "type": "boolean"
      -}
    • removedInput schema / properties / max_entries
      Removed value: -{
      -  "description": "Positive integer; returns a non-mutating summarize prompt over the most recent entries (compress).",
      -  "type": "number"
      -}
    • removedInput schema / properties / sessions
      Removed value: -{
      -  "description": "Number of recent sessions to retain live; triggers irreversible compaction (compact; default TTRPG_AUDIT_RETENTION_SESSIONS).",
      -  "type": "number"
      -}
    • removedInput schema / properties / source
      Removed value: -{
      -  "description": "Event source classification (event).",
      -  "enum": [
      -    "player",
      -    "game_master",
      -    "system",
      -    "machine"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / supersede
      Removed value: -{
      -  "description": "Ordinal of an event this observation replaces (event).",
      -  "type": "number"
      -}
    • removedInput schema / properties / text
      Removed value: -{
      -  "description": "Observation text (event).",
      -  "type": "string"
      -}
    • removedInput schema / properties / through_ordinal
      Removed value: -{
      -  "description": "Return events up to and including this ordinal (history).",
      -  "type": "number"
      -}
    • addedInput schema / properties / tier
      Added value: +{
      +  "description": "Compression tier to assemble (recap; REQ-592).",
      +  "enum": [
      +    "recent",
      +    "session",
      +    "arc",
      +    "campaign"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / properties / tool_name
      Removed value: -{
      -  "description": "Registered tool name to reassign (category).",
      -  "type": "string"
      -}
    • removedInput schema / properties / topics
      Removed value: -{
      -  "description": "Notification topics to subscribe to (subscribe).",
      -  "items": {
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
  2. Changed1 schema field changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "recap",
      -  "verbosity",
      -  "briefing_order",
      -  "compress",
      -  "compact",
      -  "health",
      -  "subscribe",
      -  "discover",
      -  "category",
      -  "event",
      -  "history"
      -]New value: +[
      +  "recap",
      +  "verbosity",
      +  "briefing_order",
      +  "discover"
      +]
  3. Addedv1.0.3

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already signal that the overall tool is mutating and destructive, and the description adds useful behavioral detail: GM-only gm_notes visibility, session-scoped verbosity, briefing_order persistence to the Novel, badge requirements, read-only recap/discover subactions, and the absence of an undo snapshot. It still does not reconcile the destructive 'compact' action that appears in the schema with the instruction to avoid audit compaction, leaving some per-action side effects unclear.

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?

The description is dense but appropriately structured for a multi-action tool: it front-loads the purpose, then gives use and do-not-use routing. Some clauses are run-on and the long action list creates slight redundancy, but most sentences carry useful information.

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

Completeness3/5

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

For a complex tool with nine parameters and an output schema, the description covers the main play-facing actions and the most important exclusions, so it is minimally viable. However, it leaves several actions present in the schema, such as compress, context_report, subscribe, verify, replay, and the visibility actions, effectively unexplained, which creates a completeness gap.

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

Parameters4/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 nine parameters. The description adds meaningful semantics beyond the schema, especially that gm_notes are GM-only and never returned to a non-GM badge, that detail schema requires query, and that briefing_order persists while verbosity is session-scoped.

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?

The description names a specific resource and enumerates four play-facing actions (recap, verbosity, briefing_order, discover), and it distinguishes this tool from story content, Novel lifecycle, and manage_diagnostics. However, the action schema includes many additional actions not covered by the description, so the stated purpose is clearer for a subset than for the full tool.

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

Usage Guidelines5/5

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

It gives explicit 'Use when' and 'Do NOT use when' guidance, naming alternatives such as manage_diagnostics for health/audit/event-log/category operations and manage_story for recording story content. The routing conditions are concrete enough that an agent can choose between this tool and its siblings without inference.

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