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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower, yet the description adds real context beyond them: it is FREE, failed calls are never charged, the server stores nothing, and the caller must retain the full text and returned StoryState. It also draws an important epistemic boundary ('a source is traceable, not proof your interpretation is true'). No annotation contradictions.

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 core purpose, cost, and statelessness are front-loaded ('FREE. Split a story conversation...'), and each sentence carries operational meaning. The full bilingual duplication effectively doubles the length, though the lang enum suggests bilingual support is intentional rather than padding.

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 tool with a deeply nested state object and an existing output schema, the description covers the non-obvious essentials: no server-side persistence, cost/idempotency behavior, and the provenance-vs-truth caveat. It omits explicit routing versus the sibling absorb_story_window and any guidance on the state/language parameters, leaving modest 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 description coverage is only 25% (essentially just request_id), so the schema does not carry the load. The description helps partially by framing that StoryState is returned and must be kept client-side, which clarifies the state round-trip, but it says nothing about the lang enum, the state sub-structure, or the conversation item shape.

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 a specific verb and resource: 'Split a story conversation (verbatim user/assistant turns) into stable, hash-anchored units.' It clarifies its role relative to the caller ('YOU judge the story; the server only slices and anchors provenance'), which distinguishes it conceptually from the sibling absorb_story_window, but it never names that 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?

Usage is implied through the workflow context ('for the Narracore Story Continuity Protocol') and the caller/server division of labor, and the idempotency note tells the agent how repeated calls behave. However, there is no explicit statement of when to use this tool versus the sibling absorb_story_window or when to skip it entirely.

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