read_file

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

The description goes well beyond the annotations. It discloses specific behaviors: mode=hash returns only SHA-256, mode=metadata avoids hashing/parsing, mode=image for PDF renders one page without OCR, XLSX formulas/caches are not recalculated, and it warns 'Never infer complete text from a truncated result.' This adds substantial value beyond the readOnlyHint and idempotentHint annotations.

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 a single dense paragraph that packs a lot of information efficiently. It is front-loaded with the core purpose and then enumerates format-specific rules. While dense, each clause serves a purpose and no extraneous text is present. The structure could be improved with bullet points, but it remains appropriately concise for the amount of detail.

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 complexity (multiple file types, modes, and constraints) and the absence of an output schema, the description covers many essential aspects: it specifies return types (images return image content, mode=hash returns only SHA-256), constraints, and a caution about truncated results. It does not fully specify the return structure for text or other formats, but it provides enough for an agent to understand the basic behavior.

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 0% schema description coverage, the description must explain parameters. It explains mode, start/limit, sheet, cell_range, and expected_sha256 implicitly via 'SHA-256'. However, it does not explicitly describe the 'expected_sha256' parameter or clarify that it is for verifying content. Workspace and path are not described, though they may be self-explanatory. The description partially compensates for the coverage gap but misses some parameter 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?

The description clearly states the tool's purpose: 'Read source with SHA-256 and ranges.' It specifies the resource (files) and the action (read), and it distinguishes itself from sibling tools by detailing format-specific behaviors and modes. It goes beyond a simple restatement of the name, offering concrete details about what it does.

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 provides clear context on when to use the tool and its constraints (line limits, page limits, cell count limits), which guides appropriate usage. However, it does not explicitly compare against alternative tools like search_files or list_directory, nor does it state 'use this instead of X.' The constraints imply usage boundaries but lack explicit exclusions.

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