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

Annotations already declare this safe, idempotent, non-destructive, and closed-world, so the bar is lower. The description adds genuinely new context (chunked reads and cross-chunk revision checking), but omits how iteration terminates, what happens on a revision mismatch, or whether expectedRevision failing throws an error.

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 compact sentences, with the primary action front-loaded and the revision caveat second. No filler, though the second sentence is terse enough to be slightly cryptic about terminology.

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-value documentation is not needed. The remaining gap is just iteration/error behavior for a read-only, idempotent tool, which is minor against the annotation coverage. The description is adequately complete for such a 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 carries the full burden. It hints at the role of contentLimit/contentOffset ('in chunks') and expectedRevision ('Check revision'), but never explains the required id vs optional pageId distinction, defaults, or offsets semantics.

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 (document root content or a named page) and adds the chunked delivery characteristic. It does not distinguish itself from the very similar siblings get_document and open_document, so an agent must still infer which one to pick.

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?

'Read ... in chunks' and 'Check revision across chunks' imply this is for incremental/paged reading, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., 'use get_document for full content'). Usage must be inferred from the sibling list.

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