holonovel

Context Controls

manage_context

Destructive

Recap play sessions, tune output verbosity, reorder briefing sections, and discover tools by name or schema. Use it to manage play-facing context controls without altering story content.

Instructions

Manage play-facing context 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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "manage_context"
  }
}

Input Schema

Name	Required	Description
`mode`	No	normal or terse (verbosity).
`tier`	No	Compression tier to assemble (recap; REQ-592).
`query`	No	Optional search term matched against tool name, description, and title (discover).
`action`	Yes	recap, verbosity, briefing_order, or discover.
`detail`	No	discover response detail: summary (default) or schema (live input schemas for the matches; requires query; REQ-609).
`format`	No	Recap/compress output notation (recap, compress; default markdown; REQ-072g).
`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).
`max_rolls`	No	Significant rolls to return, bounded 1–50 (recap; default 5; REQ-072e).
`session_id`	No	Archived session id to include in recap (recap).
`budget_tokens`	No	Positive token budget for tier assembly (recap; REQ-592) or for ledger packing (context_report; REQ-610).
`max_transitions`	No	Scene transitions to return, bounded 1–20 (recap; default 5; REQ-072e).

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

Addedv2026.10.18Nov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=true; the description adds which actions are actually read-only (recap, discover), that state changes are undone only by re-setting (no undo snapshot), that verbosity is session-scoped while briefing_order persists to the Novel and requires a GM or Editor badge, and that gm_notes are never shown to a non-GM badge. These are non-obvious authorization, durability, and reversibility facts that are not derivable from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and front-loaded: capabilities first, then behavioral constraints, then conditional routing under explicit 'Use when'/'Do NOT use when' labels. Some sentences are compressed into clause-heavy run-ons (the recap/gm_notes sentence), which costs a little readability but wastes nothing.

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 12-parameter, 4-mode tool with a live output schema and meaningful annotations, the description covers action selection, permissions, persistence scope, and sibling routing. It does not state which secondary parameters are required per action (e.g., whether briefing_order needs sections), leaving the agent to infer parameter/action pairing from the schema.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the baseline is 3; the description exceeds that by tying parameters to actions and adding semantics the schema does not carry: session_id must be an archived session, tier is optional and drives compression, gm_notes visibility is badge-gated, and detail=schema requires query. It explains the consequences of the parameters, not just their shape.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Manage play-facing context controls') and enumerates the four sub-actions it governs: recap, verbosity, briefing_order, and tool discovery. It immediately fences itself off from 'story content and Novel lifecycle', so an agent can distinguish it from manage_story and manage_novel 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.

Usage Guidelines5/5

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

Provides explicit 'Use when:' triggers (recapping play, tuning verbosity, reordering the briefing, finding a tool) and an explicit 'Do NOT use when:' list that routes health/audit/event-log/category work to manage_diagnostics and content recording to manage_story (action: record). Both directions are named with the alternative tool, leaving nothing to inference.

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