holonovel

Codex

codex

Manage reusable story elements across novels, including NPCs, factions, rooms, spells, adventures, and voice profiles. Create, list, retrieve, capture, import, and delete entries in the cross-novel library.

Instructions

Manage the cross-Novels codex library of reusable content (NPCs, factions, rooms, spells, adventures, voice profiles). Use when: storing reusable content for later import, or enumerating/reading/deleting it. Do NOT use when: storing Novel-scoped content — use lore (action: set) or note (action: set).

Input Schema

TableJSON Schema

Name	Required	Description
`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 (voice profile), import (into active Novel), or delete.
`content`	No	Entry content (for set).
`entry_id`	No	Entry identifier (for get/import/delete).
`entity_id`	No	Entity whose voice to capture (for capture).
`visibility`	No	library, shared, or private (for set).
`description`	No	Optional description (for set).
`update_source`	No	When true, update the source entity too (for capture).

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 2, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The description enumerates the action variants (set, list, get, capture, import, delete) and the openWorldHint aligns with cross-Novel reuse. It does not detail side effects or destructive implications of delete, but the annotations already indicate mutability.

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?

Two tight sentences pack the resource, operations, scoping, and disambiguation without fluff. Information is front-loaded and easy to scan.

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?

The description is sufficient for correct tool selection and covers the cross-Novel library concept, actions, and the key boundary with lore/note. No output schema is declared, so return-value documentation is not required here.

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?

All 10 parameters including the action enum are described with inline usage hints. The description adds a little context but mostly relies on the schema, which is fully covered, so a baseline score is appropriate.

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 resource (cross-Novels codex library of reusable content) and a clear set of management operations. Explicitly distinguishes it from Novel-scoped lore/note tools, leaving no ambiguity about scope.

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' and 'Do NOT use when' guidance with named alternatives (lore/note), making it easy for an agent to decide when to invoke this tool versus siblings.

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

Deploy Server

Codex

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools