ast-editor

Overview Schema Source Related Servers Discussions Admin

delete_symbol

Destructive

Deletes a whole function, method, class, or other symbol along with its doc comment and surrounding blank lines, preserving file spacing.

Instructions

Delete a whole function, method, class or other symbol, with its decorators, a JS/TS export and a C++ template <...> header. The blank lines that set it apart go too, so the file keeps its spacing. A symbol that shares a line with other code is cut out of the line. One name of a declaration of several (int a, b;, struct S {...} s;) is refused: give replace_function the declaration without it. Refused in JSON, YAML and TOML files (use delete_key).

Use this when: removing a symbol along with its doc comment. Don't use this when: removing a config key (delete_key), an import (remove_import) or lines inside a body (delete_in_body).

Example: target="LRUCache.old_method"

Input Schema

Name	Required	Description
`target`	Yes	Symbol name as list_symbols lists it, dotted for nesting (e.g. 'LRUCache.old_method', 'A.m(int)').
`file_path`	Yes	Absolute path to the source or config file.
`include_leading_comments`	No	True (default) also deletes the comment block above the symbol, or before it on its first line; false keeps it.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv3.2.0Oct 29, 2026

addedInput schema / properties / file_path / description

Added value: +"Absolute path to the source or config file."

addedInput schema / properties / include_leading_comments / description

Added value: +"True (default) also deletes the comment block above the symbol, or before it on its first line; false keeps it."

addedInput schema / properties / target / description

Added value: +"Symbol name as list_symbols lists it, dotted for nesting (e.g. 'LRUCache.old_method', 'A.m(int)')."

First observedv2.0.1May 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, but the description goes well beyond that: it discloses exactly what is removed (decorators, export keyword, template header, blank lines, optionally the doc comment), what is refused (multi-name declarations, JSON/YAML/TOML files), and how shared-line symbols are handled. This is the level of destruction detail an agent needs before calling a destructive edit.

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?

Front-loaded with the core action and its scope, then structured into when/when-not and an example. Every sentence carries information, though the opening paragraph is dense enough that a slightly tighter split would read faster.

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?

For a destructive, file-type-restricted edit tool, the description covers scope, refusals, alternatives and target addressing. An output schema exists, so return values need no explanation, and nothing an agent needs in order to call this correctly is missing.

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 both required parameters are already documented, including the dotted 'LRUCache.old_method' form and the include_leading_comments default. The description still adds real semantics by specifying that a single name from a multi-name declaration is refused and must be handled via replace_function — a constraint on the target parameter not present in the schema.

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 and resource ('Delete a whole function, method, class or other symbol') and enumerates precisely what the deletion encompasses: decorators, a JS/TS export, a C++ template header, and surrounding blank lines. An agent can distinguish this from replace_function or delete_key without opening any 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?

Includes explicit 'Use this when' and 'Don't use this when' sections that name three concrete alternatives (delete_key, remove_import, delete_in_body) and the condition selecting each. It also routes the multi-name-declaration case to a specific sibling, so there is no ambiguity left to inference.

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