holonovel

Knowledge Corpus Management

manage_corpus

Destructive

Register reference documents, route knowledge domains, control entity access, and record or inspect what each entity consumes—keeping acquired knowledge separate from belief and lore.

Instructions

Manage cold reference material and per-entity knowledge acquisition — what an entity has consumed from a registered document, distinct from belief and from lore. Registered documents create no knowledge until consumed; consumption records exactly what an entity acquired. Mutation (register, route, grant, deny, access, consume) persists to the Novel and is audited; list/get/acquisitions are read-only. Revert the most recent mutation with manage_history (action: undo). Use when: registering reference material (register), assigning its knowledge domain (route), opening or closing access (grant/deny), setting an entity's knowledge-domain profile (access), reading a document to acquire it (consume), or inspecting what an entity has acquired (acquisitions). Do NOT use when: recording beliefs — use manage_belief; recording shared world facts — use manage_lore; registering a reusable gameplay artifact — use manage_codex.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	No	Document reference text (register).
`mode`	No	read, research, taught, or import (consume; default read).
`title`	No	Document title (register).
`action`	Yes	register, list, get, route, grant, deny, access, consume, or acquisitions.
`denies`	No	Entity ids explicitly denied access (register).
`domain`	No	Knowledge domain (register/route/list).
`grants`	No	Entity ids explicitly granted access (register).
`domains`	No	Knowledge domains the entity may access (access).
`entity_id`	No	Entity acquiring or inspected (consume/acquisitions/access/grant/deny).
`document_id`	No	Corpus document id (get/route/grant/deny/consume).
`access_public`	No	Whether every entity may consume it (register; default false).
`access_domains`	No	Knowledge domains granted access (register).
`source_profile`	No	Trusted source profile the domain is routed from (register; default manual).

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

Behavior5/5

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

Annotations only give a tool-wide destructiveHint/openWorldHint, but the description adds action-level resolution: register/route/grant/deny/access/consume persist to the Novel and are audited, while list/get/acquisitions are read-only. That action-level write/read split and the audit disclosure are exactly the context annotations cannot express.

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?

Information-dense and front-loaded, with the core definition first, then mutation/read split, then use/don't-use routing. It is a single long semicolon-chained paragraph, which slightly taxes scanning for the action-to-purpose mapping.

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?

Given an output schema exists (so return values need not be explained), the description covers concept, per-action semantics, write/audit behavior, undo path, and sibling exclusions. Nothing needed to call a 13-param, enum-heavy tool correctly is missing.

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; the description goes further by tying enum action values to their parameter roles (register, route, grant/deny, access, consume, acquisitions), which helps select the right action and its companion fields. It does not add syntax or format details for individual fields beyond the schema.

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?

Names the resource (cold reference material / corpus documents) and the operations (register, route, grant/deny, access, consume, acquisitions), and crisply defines the concept: consumption records what an entity acquired, 'distinct from belief and from lore.' An agent can distinguish this from manage_belief/manage_lore/manage_codex 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?

Provides an explicit 'Use when' clause mapping each action to its intent, a 'Do NOT use when' clause naming three sibling alternatives, and routes undo to manage_history (action: undo). When-to-use, when-not-to-use, and alternatives are all present.

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