Skip to main content
Glama
sangingeum
by sangingeum

file_delete_lines

Destructive

Delete an inclusive 1-based line range from a file, with optional dry-run diff preview and undo support. Out-of-range lines are refused, and newline style and BOM are preserved.

Instructions

Delete an inclusive 1-based line range and return operation_id and undo_available.

    Out-of-range references are refused, never clamped. The file's newline
    convention and byte-order mark are preserved. dry_run returns a unified
    diff preview and writes nothing. Otherwise the operation is recorded and
    undoable.
    

Input Schema

NameRequiredDescriptionDefault
pathYes
dry_runNo
end_lineYes
start_lineYes
expected_hashNo
expected_contentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.1/5.0
Behavior5/5

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

Beyond annotations, it discloses that out-of-range references are refused rather than clamped, newline convention and BOM are preserved, dry_run writes nothing and returns a unified diff, and real operations are recorded and undoable. These are valuable behavioral details for a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core action, followed by safety and mode details. Every sentence contributes useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive file mutation with no output schema, it covers return values, dry-run behavior, preservation guarantees, and undoability well. It is only incomplete because expected_hash and expected_content are not explained anywhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies start_line/end_line as inclusive 1-based and explains dry_run, but it never mentions path, expected_hash, or expected_content, leaving important parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: delete an inclusive 1-based line range from a file. This clearly distinguishes it from sibling tools like file_delete (whole file), file_replace_lines, and file_insert_lines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the dry_run mode and states that real deletion is undoable, which gives implied usage context. However, it does not explicitly say when to choose this tool over siblings such as file_delete or file_replace_lines.

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