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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the paging mechanism (max_chunks per call, start_chunk offset, total_chunks and next_start_chunk in the response) and the metadata (including version and citation_note). It does not mention error handling or authentication, but for a read-only retrieval tool this is a strong disclosure of the key behaviors an agent needs to correctly manage long documents.

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 well-organized and efficient. It leads with the core purpose, then usage context, then paging, then return content, and finally parameter explanations in a clean list. Every sentence adds necessary information without repetition or filler. The structure makes it easy for an agent to scan and extract the important details.

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?

Given the tool's moderate complexity (paging, metadata, multiple parameters) and the existence of an output schema, the description covers all the essential aspects: how to start, how to continue reading via next_start_chunk, the nature of the returned data, and parameter semantics. It even includes guidance on citing drafts. Nothing an agent needs to successfully use this tool 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?

The input schema has zero parameter descriptions (schema coverage is 0%), so the description must compensate. It does so thoroughly in the Args section, explaining document_id (source and usage), start_chunk (zero-based offset and default), and max_chunks (default and maximum). This goes beyond the schema's bare defaults, giving the agent the semantic meaning needed to invoke the tool correctly.

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 opens with a specific action and resource: 'Retrieve the text of a specific Engelberg Center publication by document ID.' This clearly distinguishes fetch_document from its siblings: search() locates documents and list_documents() enumerates them, while this tool fetches content for a known ID. The purpose is unambiguous and differentiated.

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?

Explicitly states when to use the tool: 'Use after a search() call to get more context around a relevant chunk, or to read a paper in page order.' It also references the sibling list_documents() as a source of document_id, giving the agent a clear mental model of the workflow. No exclusions are needed because the tool has a focused role.

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