holonovel

Synthesis Management

manage_synthesis

Destructive

Manage synthesis content (voice examples, lore templates, action patterns) via run, revert, list, activate, deactivate, toggle, verify, record rulings; mutations persist and are audited.

Instructions

Manage synthesis content (voice examples, lore templates, action patterns, and other Ruleset Wisdom). Mutating actions (run, revert, activate, deactivate, toggle, toggle_action, player_add, player_remove, record_ruling, revert_ruling) persist to the Novel and are audited; read-only actions (list, player_list, verify) do not mutate state. verify checks each item's stored citation locally and reports pass/weak/unsupported; it never fetches and never changes state. record_ruling writes a ruling and its verified citations to the GM-only ruling ledger; revert_ruling marks a ledger entry reverted; ruling_list reads the ledger newest-first. Undo the latest mutation with manage_history. activate/deactivate with key omitted act on the whole module. Use when: running, reverting, listing, activating, deactivating, toggling, verifying, recording or reading rulings, or player-authoring items. Do NOT use when: browsing the codex — use manage_codex (action: list).

Input Schema

Name	Required	Description
`key`	No	Item key (activate: number; player_add/player_remove/verify/record_ruling: string).
`force`	No	Re-run even if unchanged (run).
`query`	No	Question the ruling answers (record_ruling).
`action`	Yes	run, revert, list, activate, deactivate, toggle, toggle_action, player_add, player_remove, player_list, verify, record_ruling, revert_ruling, or ruling_list.
`detail`	No	Return full entries (list).
`module`	No	Synthesis module (activate/deactivate/toggle/player_*/list/verify/record_ruling).
`ruling`	No	Ruling text to record (record_ruling).
`content`	No	Item content (player_add).
`enabled`	No	Enable or disable (toggle).
`triggers`	No	Recall triggers (player_add).
`ruling_id`	No	Ledger entry id (revert_ruling).
`badge_scope`	No	shared or player (player_add).
`max_entries`	No	Maximum rulings to return, newest first (ruling_list; default 20).
`include_reverted`	No	Include reverted rulings (ruling_list; default false).

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.

Changed2 schema fields changedv2026.10.15Oct 25, 2026
- removedInput schema / properties / key / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
```
- addedInput schema / properties / key / type
```
Added value: +[
+  "string",
+  "number"
+]
```

Changed9 schema fields changedv2026.10.13Oct 25, 2026

changedInput schema / properties / action / description

Previous value: -"run, revert, list, activate, deactivate, toggle, toggle_action, player_add, player_remove, or player_list."New value: +"run, revert, list, activate, deactivate, toggle, toggle_action, player_add, player_remove, player_list, verify, record_ruling, revert_ruling, or ruling_list."

changedInput schema / properties / action / enum

Previous value: -[
-  "run",
-  "revert",
-  "list",
-  "activate",
-  "deactivate",
-  "toggle",
-  "toggle_action",
-  "player_add",
-  "player_remove",
-  "player_list"
-]New value: +[
+  "run",
+  "revert",
+  "list",
+  "activate",
+  "deactivate",
+  "toggle",
+  "toggle_action",
+  "player_add",
+  "player_remove",
+  "player_list",
+  "verify",
+  "record_ruling",
+  "revert_ruling",
+  "ruling_list"
+]

addedInput schema / properties / include_reverted

Added value: +{
+  "description": "Include reverted rulings (ruling_list; default false).",
+  "type": "boolean"
+}

changedInput schema / properties / key / description

Previous value: -"Item key (activate: number; player_add/player_remove: string)."New value: +"Item key (activate: number; player_add/player_remove/verify/record_ruling: string)."

addedInput schema / properties / max_entries

Added value: +{
+  "description": "Maximum rulings to return, newest first (ruling_list; default 20).",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

changedInput schema / properties / module / description

Previous value: -"Synthesis module (activate/deactivate/toggle/player_*/list)."New value: +"Synthesis module (activate/deactivate/toggle/player_*/list/verify/record_ruling)."

addedInput schema / properties / query

Added value: +{
+  "description": "Question the ruling answers (record_ruling).",
+  "type": "string"
+}

addedInput schema / properties / ruling

Added value: +{
+  "description": "Ruling text to record (record_ruling).",
+  "type": "string"
+}

addedInput schema / properties / ruling_id

Added value: +{
+  "description": "Ledger entry id (revert_ruling).",
+  "type": "string"
+}

Addedv1.0.3Sep 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag a destructive, non-idempotent, non-read-only tool, and the description goes well beyond that by splitting the action enum into mutating vs read-only sets, stating mutations are audited and persist to the Novel, clarifying that verify is purely local and never fetches, and describing the GM-only ruling ledger lifecycle (record/revert/list newest-first). It even discloses the edge case that activate/deactivate with key omitted act on the whole module.

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?

Front-loaded with purpose, then the mutation/read-only split, then per-action clarifications, then the when/when-not block — a good information hierarchy. It is dense and slightly sprawling for a single sentence-chain, but nearly every clause carries distinct operational information, so waste is minimal.

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

Completeness5/5

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

For a 14-parameter, 14-action multiplexed tool with an output schema already present, the description supplies everything an agent needs to pick the right action, understand side effects, and know where to go for undo or adjacent resources. Return-value detail is correctly omitted since the output schema covers it.

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 coverage is 100% and each parameter already names its owning action, so the schema does the bulk of the work. The description still adds value the schema lacks: the whole-module behavior when key is omitted, ruling_list ordering (newest-first), and the verify pass/weak/unsupported outcome vocabulary.

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?

Opens with a specific verb+resource ('Manage synthesis content') and names the concrete content types (voice examples, lore templates, action patterns, Ruleset Wisdom). It routes away from the nearest lookalike sibling twice (manage_history for undo, manage_codex for browsing), so an agent can distinguish it without opening any 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?

Explicit 'Use when:' enumeration covers every intent the tool serves, and 'Do NOT use when: browsing the codex — use manage_codex (action: list)' names the alternative and the condition selecting it. Undo routing to manage_history is also spelled out, 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.