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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Adds substantial behavior beyond the annotations: an approval precondition, the no-overwrite semantics of conflicting edits, the expectedRevision concurrency requirement, and confirmation that identical retries leave revision history unchanged (which independently corroborates idempotentHint=true). It also explains what LOCKED status means operationally. Nothing here contradicts destructiveHint=true.

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 short sentences, all load-bearing, with the approval gate front-loaded. No filler, no restatement of the tool title.

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 the safety profile. The description covers the hard parts of a destructive optimistic-concurrency write. Only the under-documented parameters keep it from 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%, so the description carries the burden, and it only covers expectedRevision, title/kind preservation, and the LOCKED status value. The remaining parameters (content, projectId, tags, revisionReason) get no explanation, though most are self-evident from their names and enums.

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 pair (save/revise) and resource (canon), and the opening clause makes the create-or-update nature of the upsert clear. It does not name a sibling tool, so the agent must infer that search_story_canon is the retrieval counterpart, but the operation itself 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?

"Only after the user approves it" plus the explicit exclusion "brainstorming is not approval" gives a clear use gate, and "Existing entries require expectedRevision from retrieval" tells the agent the precondition for updates. What is missing is any explicit routing to siblings (e.g., use search_story_canon first to get expectedRevision).

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