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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description goes well beyond that by disclosing the ~12,000 character return cap, that page numbers are included, that truncated results end with a passage number to continue from, and that output begins with a fixed phrase. That is exactly the kind of output-shape and truncation context an agent needs for a read tool.

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, front-loaded with the core action and scope, then the return behavior, then the quirk of the reply prefix. No padding and nothing buried.

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 7-parameter read tool with no output schema, the description covers the request modes and the response shape, including the size limit and the continuation marker. An agent has enough to invoke it correctly and to handle a truncated reply.

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?

With 71% schema coverage the schema already documents ga, chapter, passage, context (including its default of 2) and continue_from, so the description does not need to repeat them. It still adds real meaning by tying continue_from and context to the continuation and context-window semantics described in prose, though it never mentions the page_from/page_to pair or the 'ga' volume format explicitly.

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 ("Reads continuous text from a volume") and enumerates the three supported scopes: whole chapter, page range, or passages around a given passage. An agent can tell this retrieves content rather than searching or counting, but the description never contrasts itself with the sibling tools like 'search' or 'count_matches', so differentiation is left implicit.

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 three-mode breakdown (chapter, page range, context around a passage) gives clear guidance on which parameter combination selects which behavior. It lacks explicit when-not guidance or a direct pointer to 'search' for locating a passage first, which is the main remaining gap.

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