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

Annotations only declare read-only, idempotent, and open-world behavior, while the description adds substantial operational detail: page size, nextOffset pagination, SHA-256 verification after reassembly, failure conditions, and the instruction to treat contents as untrusted evidence on a copy. No contradiction with the annotations exists.

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 action and resource, then gives pagination/hash verification, then caveats. Every clause carries meaningful information, though the run-on warning chain and the ambiguous phrase 'No access is granted' slightly reduce clarity.

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 paged reader with no output schema, the description covers the essential protocol: base64 pages, termination via nextOffset, SHA-256 verification, failure modes, and safe handling of untrusted content. It stops short of specifying exact response field names and error representations, but an agent has enough to invoke it correctly.

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 only 25% schema description coverage, the description compensates by explaining the paging contract ('at most 64 KiB', 'Continue nextOffset until null'), which clarifies the roles of maxBytes and offset. It also ties projectId/importId to the dossier/import context. However, it does not explicitly name parameters or fully define the offset cursor semantics, so it falls short of a 5.

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 action ('Read'), a precise resource ('the actual archived source original for an import in this dossier'), and the output form ('base64 pages of at most 64 KiB'). This clearly distinguishes it from sibling page/excerpt readers such as read_original_page and read_source_excerpt_page, even without naming them.

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 strong contextual guidance: archive availability and expiry are independent of ingestionStatus, 'unknown' must not be treated as proof of ingestion/reading/analysis/approval, and expired/changed/inaccessible originals fail. It does not explicitly name alternative tools or state 'use X instead', but the intended usage is clear.

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