Novel Save Management

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description goes beyond them by stating which actions persist (create, save_context) versus read-only (list, info, get_context) and that lifecycle changes are not reversible via manage_history, with the mitigation of cloning first. The remaining gap is that it never clarifies whether the destructive enum actions (import, clone, checkpoint_restore) are actually callable here or hard-routed to manage_archive.

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

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

Front-loaded with the action scope, then behavior (read-only vs persisting), then a risk warning, then use/do-not-use. It is dense but every sentence carries routing or safety information. The opening enumeration of twelve action names partially duplicates the action enum, which is the main redundancy.

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

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 no explanation, and the description covers routing, mutation semantics, and irreversibility for a 27-parameter tool. However, with the action enum listing export/import/clone/branch/checkpoint actions that the prose delegates to manage_archive, an agent cannot fully resolve whether those are callable here — a meaningful ambiguity for a destructive tool.

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

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

Schema coverage is 100% and each of the 27 parameters is annotated with its owning action, so the schema carries most of the load. The description adds real meaning for `detail` ('list returns one line per Novel unless detail is set') and `filter` (active/archived/all), but says nothing about the remaining parameters beyond the action-level split. Baseline 3 is appropriate.

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

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

The description names the resource (Novel save files) and enumerates the concrete actions (create, resume, switch, end, rename, info, save_context, get_context, list), so an agent can tell it handles campaign lifecycle rather than content. It explicitly separates itself from the entity tools and manage_archive. The only blur is that the schema's action enum still lists export/import/clone/branch/checkpoint_* actions the description tells the agent to route elsewhere.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit 'Use when: handling a campaign's lifecycle or returning to saved context' and 'Do NOT use when: managing content inside the Novel — use the entity tools', plus a named alternative (manage_archive) for export/import/archive/clone/checkpoints. Both the positive trigger and the exclusion are stated, 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.