str_replace_editor

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

Transparency is high: no annotations are present, so the description takes the full burden. Detailed behavioral information is abundant, exposing persistence, the behavior of view when file vs. directory, the inability to create an existing file, truncation of long outputs with the marker, and the exact conditions of str_replace.

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 text is long, but structured with sections and command-scoped notes. It is organized by command, then by operational notes (view, insert, str_replace) with clear field labels. The amount of detail useful is given by the complexity of the tool, and is not verbose.

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?

There is no output scheme, but the description provides a complete operational picture even without a return description: command list, state persistence, file vs directory behavior in view, truncation of long output, create and insert restrictions, and the str_replace disambiguation rules are all present. Well covered for a tool that accepts many parameters and custom states.

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?

Although the input schema already covers 100% of the parameters, the descriptions go further with practical semantics: for str_replace, old_str refers to exact/consecutive line matching and uniqueness; new_str is optional semantics; file_text is used in create; view_range explains mixed ranges with 1-based indexing and -1 sentinel; insert_line includes his post-insertion rule.

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?

Description opens with specific verb and resource ('custom editing tool for viewing, creating and editing files'), then lists the four commands (view, create, str_replace, insert) with their exact semantics. Its 'custom editing tool' framing distinguishes it from a generic bash/shell tool.

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 explicitly defines what the tool does and explains each command's role. The directives include operational caveats (persistent state, directory vs. file output of view, no overwrite on create, output truncation marker) and dedicated notes on how to use str_replace (exact line match, uniqueness requirement, whitespace sensitivity). These rules are stated directly in the tool description.

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