holonovel

Session Management

manage_session

Destructive

Handle session-level diagnostics, verbosity, briefing order, health checks, and tool discovery for Holonovel; append or read the Novel event log.

Instructions

Manage session-level surfaces, diagnostics, and tool discovery. event with supersede appends a replacement and marks that ordinal superseded. Use when: recapping recent activity (recap), setting output verbosity (verbosity), reordering briefing sections (briefing_order), summarizing the audit log (compress) or compacting it irreversibly (compact), reporting server health (health), discovering or searching the tool catalog (discover), reassigning a tool's category for the session (category), or appending and reading the Novel event log (event, history). Category reassignment, event append, and audit compaction mutate Novel-scoped state and persist; recap/verbosity/briefing_order/health/discover/history are read-only diagnostics or session-scoped settings. Do NOT use when: recording story content — use manage_story (action: record).

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	normal or terse (verbosity).
`text`	No	Observation text (event).
`query`	No	Optional search term matched against tool name, description, and title (discover).
`action`	Yes	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).
`source`	No	Event source classification (event).
`topics`	No	Notification topics to subscribe to (subscribe).
`category`	No	New category label, or null/empty to restore the default (category).
`gm_notes`	No	GM-only free-text notes returned only to the Game Master badge (recap).
`sections`	No	Ordered list of briefing sections (briefing_order).
`sessions`	No	Number of recent sessions to retain live; triggers irreversible compaction (compact; default TTRPG_AUDIT_RETENTION_SESSIONS).
`supersede`	No	Ordinal of an event this observation replaces (event).
`tool_name`	No	Registered tool name to reassign (category).
`session_id`	No	Archived session id to include in recap (recap).
`max_entries`	No	Positive integer; returns a non-mutating summarize prompt over the most recent entries (compress).
`through_ordinal`	No	Return events up to and including this ordinal (history).
`include_superseded`	No	Include superseded events (history; default true).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`text`	No	Human-readable text envelope mirroring the structured result (REQ-001, REQ-548a).
`status`	Yes	Machine-readable result status: OK, NEED_INPUT, WARNING, PARTIAL, or an error category (REQ-002, REQ-548c).

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.3Sep 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only flag the tool globally as destructive/non-idempotent, which is conservative for a multi-action tool; the description adds real value by partitioning the actions into mutating ('category reassignment, event append, and audit compaction mutate Novel-scoped state and persist') versus read-only ('recap/verbosity/briefing_order/health/discover/history'). It also calls out that compaction is irreversible and that supersede marks the replaced ordinal. No contradiction with annotations.

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?

Given eleven actions, the description is compact and front-loaded, moving from a one-line purpose to the mutation summary to 'Use when:' and 'Do NOT use when:'. The action-to-intent parentheticals keep it scannable. It is dense but each clause earns its place for a tool of this breadth.

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?

An output schema exists, so return values need no explanation, and the description covers usage, mutation semantics, irreversibility, and the sibling exclusion. The remaining gap is minimal: no guidance on permission requirements beyond the schema's GM-only note, but nothing an agent needs to invoke correctly is missing.

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 16 parameters with per-action hints. The description maps some actions to their parameters but adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 3 is appropriate when the schema carries the load.

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 the resource (session-level surfaces, diagnostics, tool discovery) and enumerates the concrete actions it fronts (recap, verbosity, briefing_order, compress, compact, health, discover, category, event, history). It also distinguishes itself from a sibling by name (manage_story for recording story content). The verb 'Manage' is broad and the scope is sprawling, which keeps it out of 5 territory, but the action enumeration makes the purpose unambiguous.

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 provides an explicit 'Use when:' mapping each action to its intent (recapping activity, setting verbosity, reordering briefing sections, summarizing/compacting the audit log, health, discovery, category reassignment, event/history) and an explicit 'Do NOT use when:' clause naming the alternative (manage_story, action: record). This is textbook when/when-not/alternative guidance.

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