Skip to main content
Glama

delete_in_body

Destructive

Deletes a matched snippet from a function body, preserving trailing comments and refusing to empty Python bodies. Use to remove statements, blocks, lines, or object literal entries.

Instructions

Delete a snippet inside a function's body, matched as replace_in_body matches one. A deletion that empties its lines removes them whole; a comment after the snippet on its last line stays. One that would leave a Python body without a statement is refused (replace the snippet with pass).

Use this when: removing a statement, block or line in a body, or an entry of an object literal passed as an argument. Don't use this when: deleting a whole function or class (delete_symbol).

Example: target="RegisterRoutes" snippet='r.Mount("/kb", kbHandler)'

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_path": "<file_path>",
      "target": "<target>",
      "snippet": "<snippet>"
    },
    "name": "delete_in_body"
  }
}

Input Schema

NameRequiredDescriptionDefault
targetYesFunction or method name as list_symbols lists it, dotted for nesting ('LRUCache.get'); overloads take parameter types ('A.m(int)').
snippetYesText in the target's body, matching one place: its exact text at token boundaries, or else whole lines with the same indentation added to or removed from each.
file_pathYesAbsolute path to the source or config file.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.2.0
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the source or config file."
    • addedInput schema / properties / snippet / description
      Added value: +"Text in the target's body, matching one place: its exact text at token boundaries, or else whole lines with the same indentation added to or removed from each."
    • addedInput schema / properties / target / description
      Added value: +"Function or method name as list_symbols lists it, dotted for nesting ('LRUCache.get'); overloads take parameter types ('A.m(int)')."
  2. Addedv2.10.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description earns credit by disclosing the non-obvious semantics beyond that: lines that empty are removed whole, a trailing comment on the last line survives, and a deletion that would empty a Python body is refused with a prescribed workaround. It stops short of describing what is returned or how other failure modes surface, so a 4 rather than a 5.

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

Conciseness4/5

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

Dense but every sentence carries content: behavior, exclusions, and an example. Front-loading the behavioral rules ahead of the use/don't-use rubric is slightly inverted for scanning, but nothing is redundant.

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

Completeness5/5

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

Three required parameters, all schema-documented at 100%, an output schema exists so return values need no prose, and annotations cover the destructive profile. The description supplies exactly the remaining gaps: matching semantics, edge-case behavior, and sibling routing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description goes beyond it with a concrete example pairing target="RegisterRoutes" with snippet='r.Mount("/kb", kbHandler)', showing the target/snippet relationship in practice. It adds no syntax detail for file_path and defers snippet matching rules to replace_in_body, so not a 5.

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?

States a specific verb (Delete) plus a precise resource scope (a snippet inside a function's body), and immediately distinguishes itself from the broad-brush alternative by naming delete_symbol. An agent can tell it apart from replace_in_body and delete_symbol without opening a schema.

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

Usage Guidelines5/5

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

Explicit 'Use this when' enumerates the concrete cases (statement, block, line, object-literal entry as argument) and an explicit 'Don't use this when' routes whole-function/class removal to delete_symbol. That is a complete when/when-not with a named alternative.

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