docs_read

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the chunked-read model, the default and maximum chunk sizes, and how continuation works via next_offset. It does not mention any rate limits or failure modes for bad ids.

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?

Front-loads the one-line purpose, then structures Args and Returns explicitly, which is easy to parse. The multilingual keyword tail ('leer documentacion, seguir leyendo...') is redundant for a model already reading the English description, but it is conventional for retrieval-style tools and costs little.

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 3-parameter, no-output-schema tool, the description supplies everything needed: purpose, id provenance, pagination mechanics, size limits, and even the exact return object keys ({found, qualname, library, text, offset, total_chars, has_more, next_offset}). Nothing an agent needs to invoke it correctly is missing.

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 and does so: id is 'passed back exactly', offset is a character offset to continue from using next_offset, and max_chars has a stated default of 4000 and a hard max of 20000. Every parameter is documented with semantics the bare schema lacks.

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 ('Read the full text of one doc entry by id') plus the delivery mode ('in chunks'), which cleanly separates it from docs_search and docs_catalog. It also defines what an 'entry' is (docset page section, markdown section, long docstring), removing ambiguity about the unit being read.

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?

Gives concrete provenance for the required id ('Ids come from docs_search results and from api_lookup (field id)') and tells the agent how to continue reading via next_offset. It stops short of an explicit when-not rule (e.g. 'use docs_search first to find ids'), but the routing context is clear.

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