Story continuity, novel memory, and series bible for fiction writers, shared with AI assistants
Scored across 11 tools
Each tool has a fairly distinct resource+action target, and descriptions actively disambiguate overlapping retrieval tools (get_continuity_context vs search_story_canon vs get_canon_history). Minor risk of confusion remains between list_approved_scenes and get_continuity_context, which both surface scene content, but the stated selection-vs-verification split keeps them mostly separable.
Nearly all tools follow a verb_noun pattern (create_story_project, get_canon_history, list_approved_scenes, save_story_checkpoint, upsert_canon_entry) with consistent domain prefixes for story/canon/scene/checkpoint. continuity_audit breaks the pattern as noun_verb instead of audit_continuity, a minor deviation.
11 tools sit squarely in the well-scoped range and each maps to a distinct part of the continuity workflow (projects, canon, scenes, checkpoints, context, audit). No redundant or filler tools are apparent.
The surface covers the core lifecycle: create/list projects, upsert/search/history canon, record/list scenes, save/list checkpoints, and audit. Gaps are deletion/update of projects, scenes, and checkpoints, likely intentional for an append-only canon model, so agents can work around them.
Retrieve locked canon for the assistant to compare against a short proposed scene. This tool supplies evidence; the assistant must identify contradictions. Does not save or approve the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| projectId | Yes | ||
| proposedText | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by clarifying the division of labor ('supplies evidence; the assistant must identify contradictions') and that it does not mutate state ('Does not save or approve the scene'), but it says nothing about result size limits or what the offset-driven paging returns.
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?
Three short sentences with no filler, and the retrieval purpose is front-loaded before the responsibility caveat. Efficient, though the middle sentence's emphasis on the assistant's job is slightly instructional rather than descriptive.
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 not be described. But for a tool with an unexplained offset parameter and an unnamed near-duplicate sibling, the definition leaves meaningful gaps about result volume and how this differs from get_continuity_context.
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 description coverage is 0% across all three parameters, so the description carries the full burden. Only 'short proposed scene' hints at proposedText's size constraint; projectId and offset (clearly a pagination cursor) are left entirely unexplained.
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?
States a specific verb and resource ('Retrieve locked canon') plus the intended use ('compare against a short proposed scene'), which is far more than a restatement of the name. However, it never distinguishes itself from the close sibling get_continuity_context, so an agent cannot tell the two apart from text alone.
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?
Usage is implied rather than stated: the agent learns it should feed a proposed scene in and then perform the comparison itself. There is no explicit when-not or naming of alternatives (get_continuity_context, search_story_canon), which matters given several canon-reading siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new private story project when the user asks. Does not save canon or scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds the 'private' visibility scope and clarifies the operation does not touch canon or scenes, which is useful mutation-boundary context. It says nothing about permissions, reversibility, or what the created project contains.
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?
Two short sentences, front-loaded with the core action and followed by the scope exclusion. No padding, though 'when the user asks' is low-information filler that could be sharpened.
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 not be explained, and the parameter set is small. However, with 0% schema coverage the description leaves both parameters semantically undefined, which is the main completeness gap for an otherwise simple create 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 description coverage is 0% — neither 'name' nor 'description' has any documentation in the schema, and the description adds nothing about their meaning, length limits, or expected content. For a 2-param tool with zero coverage, the description should have compensated and does not.
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?
States a specific verb and resource ('Create a new private story project') and adds the distinguishing 'private' qualifier. The follow-up sentence ('Does not save canon or scenes') separates it from canon/scene siblings, though it never names an alternative tool directly.
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?
The trigger condition is only 'when the user asks,' which is vague and applies to nearly any tool. The exclusion ('Does not save canon or scenes') does hint at when to prefer siblings like upsert_canon_entry, but no explicit alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read previous and new content for a saved canon entry, newest first. No changes are made.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| canonEntryId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful ordering behavior ('newest first') but 'No changes are made' largely repeats the annotations rather than adding new behavioral context. It does not explain pagination or rate limits.
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?
Two short sentences, front-loaded with the action and result. 'No changes are made' is somewhat redundant against annotations, but overall efficient.
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?
For a simple two-parameter read tool with an output schema and rich annotations, the definition is nearly complete, but the absence of offset/pagination semantics leaves a real invocation gap. It doesn't need to explain return values because output schema exists.
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 description coverage is 0%, so the description must compensate, but it only alludes to canonEntryId via 'saved canon entry' and never mentions the offset parameter or its pagination role. It adds little semantic meaning beyond the schema property names.
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?
States a specific verb ('Read') and resource ('previous and new content for a saved canon entry'), with scope ('newest first'). It clearly separates this version-history read from siblings like search_story_canon or upsert_canon_entry, though it does not name any sibling explicitly.
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?
No explicit when-to-use, prerequisites, or alternatives. The description only implies usage from the purpose statement; it does not say when to choose this over search_story_canon or get_continuity_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve relevant canon, recent approved scenes, and the latest provisional checkpoint before continuing a saved story or recovering it in a new chat. request is a brief scene/topic query, never a chat transcript. Results are a selection; use search_story_canon for specific missing facts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| request | Yes | ||
| projectId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/non-openWorld, so the safety profile is handled. The description still adds real behavior: results are a partial selection rather than a complete set, which shapes how the agent should follow up. It doesn't cover latency, auth, or response shape, keeping it short of a 5.
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?
Three sentences, zero filler, front-loaded with purpose before the invocation constraint and the sibling alternative. Each sentence earns its place.
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 not be explained, and annotations cover safety. The description fully covers purpose and routing; only the semantics of projectId and limit are left implicit, a minor gap for an otherwise self-explanatory read 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 description coverage is 0%, so the description must carry parameter meaning; it clarifies only `request` (brief scene/topic query, not a transcript) and says nothing about projectId or limit. That is meaningful compensation for one of three parameters but leaves the rest undocumented.
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?
States a specific verb (Retrieve) and precise resource set (canon, recent approved scenes, latest provisional checkpoint), plus the triggering situation (continuing a saved story or recovering it in a new chat). An agent can distinguish it from siblings like search_story_canon or get_canon_history without opening the schema.
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?
Gives the when explicitly ('before continuing a saved story or recovering it in a new chat') and names the alternative with its selecting condition ('use search_story_canon for specific missing facts'). It also warns that results are a selection, which tells the agent not to expect exhaustiveness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read approved scene summaries in story order. Page with offset to inspect older scenes or verify a scene number before saving.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| projectId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations by specifying that results are summarized and returned in story order, and that pagination is available via offset.
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?
Two tightly written sentences. The purpose is front-loaded, followed immediately by the paging/verification guidance. No wasted words.
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?
For a simple two-parameter read-only list tool with an output schema and safety annotations, the description covers purpose, ordering, and paging adequately. The main gap is the absence of any textual explanation for the required projectId parameter.
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 description coverage is 0%, so the description must compensate. It explains the offset parameter's purpose ('Page with offset to inspect older scenes'), but says nothing about the required projectId parameter. An agent must infer its meaning from the name and UUID format alone.
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?
States a specific verb (Read) and resource (approved scene summaries) with an ordering constraint (story order). It is distinct from sibling tools like record_approved_scene or search_story_canon, but does not explicitly name a sibling alternative to reinforce the boundary.
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?
Gives a clear use case: 'Page with offset to inspect older scenes or verify a scene number before saving.' This tells the agent when to use the offset parameter, but does not state when not to use the tool or explicitly compare it to any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve provisional story handoffs to recover progress across chats. These notes never override approved canon. Page with offset for older checkpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| projectId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior. The description adds genuinely useful framing beyond that — these are provisional notes that never override approved canon — but says nothing about return shape, freshness, or how provisional notes are populated/expire.
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?
Three tight sentences, front-loaded with the core purpose and no filler. Slight cost: the pagination note is appended after the canon caveat rather than grouped with retrieval semantics.
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?
With rich annotations and an output schema present, the description only needs the non-obvious facts, and it delivers the key ones (provisional nature, canon precedence, paging). It is complete enough to call correctly, though the required projectId is left unqualified.
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 description coverage is 0%, so the description must carry the parameter burden. It does explain offset as the mechanism for reaching older checkpoints, but projectId (the required parameter) gets no explanation of scope at all.
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?
States a specific verb and resource ('Retrieve provisional story handoffs to recover progress across chats') and implicitly separates itself from canon tools via 'never override approved canon'. It doesn't name a sibling outright (e.g. get_canon_history or search_story_canon), so 4 rather than 5.
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?
Gives one concrete usage instruction — use offset to page to older checkpoints — and hints at scope via the canon caveat. It never states when to prefer this over sibling tools like get_continuity_context or get_canon_history, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the user’s saved story projects before starting or resuming a story. Use the returned ID; do not guess projects. Page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered by structured data. The description adds the pagination behavior and the anti-guessing constraint, a modest but real contribution beyond the annotations.
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?
Three short sentences, front-loaded with the purpose and then the two behavioral constraints. Every sentence carries actionable information with no filler.
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?
With an output schema present, return values needn't be described, and purpose, usage timing, ID handling, and paging are all covered. Only a hint about ordering or result limits is absent, which is minor.
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 description coverage is 0% for the single 'offset' parameter, but the description says 'Page with offset', conveying its pagination role. The schema supplies bounds/default but no meaning; the description adds the key semantic hint, though not full detail.
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?
States a specific verb+resource ('Find the user's saved story projects'), which clearly separates it from the sibling create_story_project. It does not explicitly contrast with the other list_* siblings, so it falls just short of 5.
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?
Gives a clear usage context ('before starting or resuming a story') and a strong operational directive ('Use the returned ID; do not guess projects'), which prevents an agent from fabricating IDs. No alternative tool is named, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a concise summary of a scene the user has approved. Never record an unapproved draft. An occupied scene number is preserved unless replaceExisting is true and the user requested replacement. Identical retries return the saved scene.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| summary | Yes | ||
| projectId | Yes | ||
| sceneNumber | Yes | ||
| continuityNotes | No | ||
| replaceExisting | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true; the description adds valuable specifics beyond them: occupied scene numbers are preserved unless replaceExisting is true and the user requested replacement, and identical retries return the saved scene. It does not state auth requirements, but the mutation semantics are well disclosed.
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?
Three sentences, no filler, with the approval constraint front-loaded and the replaceExisting behavior immediately after. Every sentence carries distinct, load-bearing information.
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?
For a mutation tool with an output schema, the description covers the key behavioral risks (accidental overwrite, unapproved drafts, retry behavior). The remaining gap is undocumented parameters like title and continuityNotes, but the core invocation semantics are complete.
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 description coverage is 0% across 6 params, but the description clarifies the most consequential one, replaceExisting, including the prerequisite that the user must have requested replacement. It says nothing about title, projectId, or continuityNotes, leaving half the parameters undocumented.
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?
States a specific verb and resource: 'Store a concise summary of a scene the user has approved.' An agent can distinguish this write tool from the read-only sibling list_approved_scenes, though no sibling is named explicitly.
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 a clear negative condition ('Never record an unapproved draft') and a conditional for replacement, which gives real when-to-use guidance. It does not name alternatives such as list_approved_scenes, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preserve a concise story-session handoff when the user asks to save progress or has authorized ongoing checkpoints for this story. Stores provisional notes, not canon or an approved scene. Separate established progress from unresolved ideas. Send only focused story state, never a full transcript, credentials, or unrelated personal details. Reuse checkpointId on retries.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| nextSteps | No | ||
| projectId | Yes | ||
| storyState | Yes | ||
| openThreads | No | ||
| checkpointId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which cover mutation, idempotency, and safety), the description adds meaningful behavioral context: provisional rather than canon status, separation of established progress from unresolved ideas, a restriction against sending transcripts/credentials/personal details, and retry guidance. These additions are substantial and consistent with the annotations.
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?
The description is front-loaded with the core purpose, then adds constraints and retry behavior in tightly packed sentences. Every sentence serves a distinct function—purpose, scope limitation, content partitioning, safety restriction, and idempotency—with no filler.
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?
Given the rich annotations and the presence of an output schema, the description covers purpose, usage conditions, content restrictions, and retry semantics well. The main gap is parameter-level detail for a 6-parameter tool with zero schema description coverage, though the parameter names are mostly self-explanatory enough for an agent to proceed.
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 description coverage is 0% and there are 6 parameters, so the description carries the full burden. It explicitly mentions checkpointId ('Reuse checkpointId on retries') and gives content guidance that loosely maps to storyState and openThreads, but it never explains title, projectId, nextSteps, or the required format/length constraints, leaving most parameter semantics undocumented.
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 states a specific verb ('Preserve', 'Stores') and resource ('story-session handoff', 'provisional notes'), and explicitly distinguishes what it is not ('not canon or an approved scene'). This differentiates it from siblings like upsert_canon_entry and record_approved_scene without needing to open any schema.
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?
It gives clear conditions for use ('when the user asks to save progress or has authorized ongoing checkpoints') and implicit exclusions ('not canon or an approved scene'). However, it does not explicitly name alternative tools or state when to use a sibling instead, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search saved canon by literal title/content text, or browse every entry with an empty query and offset. Use to verify details before revising an entry or when context retrieval omits something.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| offset | No | ||
| projectId | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds that an empty query browses every entry and that offset is used in that mode, but it does not disclose pagination limits, result ordering, or any auth requirements beyond what the annotations imply.
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?
Two sentences with no wasted words, front-loading the core search/browse capability before the usage guidance.
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 not be described. For a three-parameter read search tool, the description is nearly complete, though projectId semantics and pagination bounds remain implicit.
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 description coverage is 0%, so the description must compensate. It explains query as literal title/content matching and links empty query plus offset to browsing, but projectId is left completely unexplained, so the compensation is partial.
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?
States a specific verb and resource (search saved canon) and clarifies it supports both literal text search and empty-query browsing. It distinguishes the operation from write siblings like upsert_canon_entry, but does not explicitly name or rule out read alternatives such as get_canon_history.
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?
Gives concrete usage contexts: verify details before revising an entry, or when context retrieval omits something. No explicit when-not condition or named alternative is provided, but the guidance is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a fact or revise canon only after the user approves it. Preserve the existing title/kind. LOCKED requires approval as established fact; brainstorming is not approval. Existing entries require expectedRevision from retrieval; conflicting edits fail without overwriting. Identical retries leave revision history unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| tags | No | ||
| canon | No | false marks a temporary, alternate, or what-if entry as non-canon. Omit to keep the current value; new entries default to canon. | |
| title | Yes | ||
| status | Yes | ||
| content | Yes | ||
| expiresAt | No | Optional ISO 8601 date or datetime after which a non-canon or temporary entry expires. Omit to keep, null to clear. | |
| projectId | Yes | ||
| revisionReason | No | ||
| expectedRevision | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial value beyond annotations: explains approval requirement, optimistic concurrency via expectedRevision, conflict failure without overwrite, and idempotent retry behavior. Annotations already signal destructive/idempotent, but the description clarifies the failure semantics.
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?
Five dense sentences with no filler, front-loaded with the approval prerequisite. Slightly terse but each sentence carries behavioral weight.
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?
For a 10-param mutation with output schema and low schema coverage, the description covers the critical approval and conflict semantics but leaves several parameters ('canon', 'expiresAt', 'revisionReason') and the return shape unexplained. Adequate but with notable gaps.
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 only 20%, so the description must compensate. It clarifies expectedRevision ('from retrieval; conflicting edits fail without overwriting') and implicitly the title/kind preservation, but other parameters (canon, expiresAt, revisionReason, tags) get no mention. Baseline 3 given partial compensation.
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?
States a clear verb+resource ('Save a fact or revise canon') and distinguishes from siblings by emphasizing the approval precondition. No sibling is explicitly named as an alternative, keeping it from a 5, but the purpose is unambiguous.
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 strong when-to-use guidance: 'only after the user approves it,' 'LOCKED requires approval as established fact; brainstorming is not approval.' It does not explicitly name search_story_canon or get_canon_history as the retrieval alternative, but the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
upsert_canon_entry2 fields changedInput schema / properties / canonAdded value: +{
+ "description": "false marks a temporary, alternate, or what-if entry as non-canon. Omit to keep the current value; new entries default to canon.",
+ "type": "boolean"
+}Input schema / properties / expiresAtAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 40,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Optional ISO 8601 date or datetime after which a non-canon or temporary entry expires. Omit to keep, null to clear."
+}continuity_auditcreate_story_projectget_canon_historyget_continuity_contextlist_approved_sceneslist_story_checkpointslist_story_projectsrecord_approved_scenesave_story_checkpointsearch_story_canonupsert_canon_entryA structured story bible for long-form fiction: scenes, characters, world, plot and foreshadowing.
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Campaign manager for D&D and TTRPG GMs: your AI reads and writes a live typed campaign database.
Encrypted long-term memory shared across your AI assistants (Claude, ChatGPT, Perplexity).
Add one secure layer between your agents and this server.