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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior beyond the schema: text is 'verified against its indexed hash' (implying possible verification failure) and 'One request' hints at single-shot retrieval with no pagination. It omits what happens on hash mismatch, any rate limits, or how max_chars truncation behaves.

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 tight sentences with no filler; the identity rule for sha256 and the offset linkage are front-loaded before the 'One request' note. Slightly cryptic phrasing ('AnyDoc', 'One request') costs it the top mark rather than any verbosity.

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?

The description covers the core contract for a 3-param read tool with no annotations and no output schema: it says the return is the document's extracted text and how the sha256 is resolved. It leaves max_chars and nb_id semantics unaddressed, which is a real gap given zero schema coverage.

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 adds real meaning for sha256 (either the text sha256 or the original sha256 from get_evidence), but nb_id and especially max_chars are left completely undefined, including whether max_chars truncates or errors.

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?

Names a specific verb+resource ('extracted text of one document') and pins the sha256 identity to the get_evidence flow, which distinguishes it from get_document_download at a high level. It does not explicitly contrast itself with the sibling download tool, and 'AnyDoc' is jargon an agent may not resolve, but the retrieve-text purpose is 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?

Implies usage context by tying sha256 to 'the original sha256 from get_evidence' and stating offsets from get_evidence index into this text, which routes the agent in the right sequence. However, there is no explicit when-to-use vs get_document_download or when-not guidance, so the caller must infer the distinction.

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