read_file

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states the tool reads and retrieves complete content, implying a non-destructive operation. However, it does not disclose error handling (e.g., missing file) or performance characteristics, though for a simple read tool the description is sufficiently transparent about its core behavior.

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 includes a clear first sentence, but it is somewhat verbose with a repeated keyword list and bilingual content. There is redundancy between the description and the schema's description, and the keyword list is not essential. The structure is acceptable but not maximally concise.

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 tool is simple with one parameter and an output schema present, so the description does not need to explain return values. It covers purpose, usage scenarios, and distinguishes from siblings. The lack of error handling or permission notes is a minor gap, but overall the description is complete for this tool's complexity.

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 100% and the parameter 'path' is thoroughly documented with examples and constraints. The description adds little beyond the schema (mostly repeating the purpose), so the baseline score of 3 applies.

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 identifies the tool as a file reader: 'READ AND RETRIEVE complete file content' and labels it the 'Primary tool for reading files'. It is explicitly differentiated from sibling tools like write_file, search_files, and file_stat by stating it retrieves complete content, making its purpose 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?

The description provides clear usage context: 'use whenever you need to see what's inside a file' and lists specific use cases (viewing, inspecting, checking before modification). It does not explicitly state when not to use the tool, but the 'Primary tool' designation and examples effectively guide selection over alternatives.

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