get_original

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

With no annotations, the description carries the full behavioral burden and does so well. It discloses that the response mirrors the UI panel, that chunk_id is a never-changing database cache id, that it is only valid within the book, that merged-translation responses include blocks with alignment implications, that include_raw returns raw HTML, and that the response echoes book_id and title for verification. This is exceptional transparency.

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?

Every sentence adds meaningful information: main purpose, parameter semantics, cross-book warning, merged-translation alignment caveat, raw HTML option, and response verification. The description is front-loaded with the core purpose and then layers caveats logically. No filler is present.

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 tool complexity and the absence of annotations, the description covers all critical context: what the tool returns, how to obtain a valid chunk_id, the cross-book invalidity caveat, the interaction with merged translations, the optional raw HTML flag, and verification of the returned book. The presence of an output schema means detailed return-field explanation is unnecessary.

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 thoroughly explains chunk_id semantics, the meaning and effect of include_raw, and notes that book_id/title are echoed for verification. The only minor gap is that book_id itself is not directly defined, though its role is inferable from the sibling list_books tool.

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 opens with a specific verb and resource: 'Read the full original text of one chunk.' It also clarifies this is the exact text the human UI proofreading panel shows, which clearly distinguishes it from translation-related tools like get_translation. The purpose is immediately 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?

The description gives clear context on when to use the tool: when the full original text of a chunk is needed. It also instructs the agent to obtain chunk_id via list_chunks and warns that the ID is scoped to the current book. It stops short of explicitly naming alternatives or saying when not to use it, but the usage context is strong.

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