holonovel

Codex Library Management

manage_codex

Destructive

Store and manage reusable RPG content across Novels—NPCs, factions, rooms, spells, adventures, and voice profiles—so you can list, import, capture, or delete entries for later use.

Instructions

Manage the cross-Novels codex library of reusable content (NPCs, factions, rooms, spells, adventures, voice profiles). Mutating actions persist to the Novel and are audited; read-only actions do not mutate state. Revert the most recent mutation with manage_history (action: undo). capture's source_id falls back to entity_id; update_source requires artifact provenance. Use when: storing reusable content for later import, or enumerating/reading/deleting it. Do NOT use when: storing Novel-scoped content — use manage_lore (action: set) or manage_note (action: set).

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Entry identifier or array of identifiers (for import/get/delete).
`kind`	No	Entry kind (for set/list/capture).
`name`	No	Entry name (for set).
`tags`	No	Optional tags (for set).
`action`	Yes	set (create/update), list, get, capture (Novel artifact per kind), import (into active Novel), or delete.
`content`	No	Entry content (for set).
`entry_id`	No	Entry identifier (for get/import/delete); alias of `id`.
`entity_id`	No	Entity whose voice to capture (for capture, voice_profile kind).
`source_id`	No	Novel artifact key/name/entity id to capture (for capture). Defaults per kind.
`visibility`	No	library, shared, or private (for set).
`description`	No	Optional description (for set).
`update_source`	No	When true, update the source Codex entry in place (for capture).

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.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, so safety is partly covered. The description adds valuable context beyond annotations: that mutations persist to the Novel and are audited while reads do not mutate, and that update_source requires artifact provenance and capture's source_id fallback. It could still note irreversibility of delete more explicitly, but the audit/persistence details are strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Dense but every clause earns its place: purpose, mutation/audit semantics, undo route, parameter fallbacks, and explicit when/when-not with alternatives. Front-loaded with the core purpose before routing guidance.

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?

An output schema exists so return values need not be explained. Combined with annotations covering safety and the description covering scoping, persistence/audit, undo, parameter fallbacks, and sibling routing, an agent has everything needed to call this correctly.

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% so the baseline is 3, but the description adds genuine semantics beyond the schema: capture's source_id fallback to entity_id, and update_source requiring artifact provenance. These are behavioral constraints on parameters not spelled out in the schema descriptions.

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 and resource: managing a cross-Novels codex library of reusable content, and enumerates the kinds (NPCs, factions, rooms, spells, adventures, voice profiles). It distinguishes itself from siblings by explicitly naming manage_lore and manage_note as the route for Novel-scoped content.

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 when-to-use (storing reusable content for later import, enumerating/reading/deleting) and when-not-to-use with concrete alternatives (manage_lore action:set, manage_note action:set). It also routes undo to manage_history and states provenance requirements for update_source.

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