Skip to main content
Glama

safe_delete_symbol

Delete a symbol's declaration only when no references remain, preventing accidental removal of in-use code. If references exist, the deletion is rejected and referencing locations are listed.

Instructions

Delete a symbol's declaration only if it has no remaining references.

Calls LSP textDocument/references first. If any reference outside the declaration itself is found, the deletion is rejected with the list of referencing locations so the caller can decide what to do. This prevents accidental deletion of code that's still in use.

Set include_doc_comment=true to also delete any contiguous doc comment above the symbol — otherwise the comment is left orphaned, pointing at whatever ends up next in the file.

The response includes a unified diff of the deletion — a preview in dry-run, the applied change otherwise — unless show_write_diff is disabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriNoAbsolute path, file:// URI, or workspace-relative path.
dry_runNoIf true (default), preview only; do not write.
dirty_okNoAllow editing a file with uncommitted changes. Default false — review/commit first, or pass true to proceed.
name_pathYesSlash-separated symbol path within the file (e.g. "ClassName/methodName", or just "funcName" for top-level).
include_doc_commentNoIf true, extend the operation to cover any contiguous comment lines (//, #, /*, *) directly above the symbol declaration. Lets you replace/delete a function together with its doc comment, or insert a new block above an existing doc comment instead of between the comment and its symbol. A WRAPPED declaration (an exported ES declaration under its export statement, a decorated Python def under its @decorator) keeps its doc comment above the wrapper, so WHEN SUCH A COMMENT EXISTS insert_before_symbol and replace_symbol_body extend past the wrapper — replacement content must then reproduce the export keyword or the decorator, or it is dropped. With no doc comment above the wrapper the range starts at the declaration and the wrapper is untouched; safe_delete_symbol never extends past the declaration at all.
Behavior5/5

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

With no annotations, the description fully discloses important behaviors: it calls LSP references, rejects with referencing locations, handles orphaned doc comments, offers dry-run preview, and respects dirty_ok. This gives the agent a complete picture of side effects and safety guarantees.

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?

The description is concise but comprehensive, using four focused paragraphs to cover core behavior, reference check, doc comment handling, and diff response. It is well-structured and avoids unnecessary fluff, though slightly longer than minimal.

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?

Given the tool's complexity (5 params, no output schema, no annotations), the description covers the essential contextual aspects: safety mechanism, dry-run, dirty_ok, doc comment behavior, and response content. It is thorough enough for reliable invocation, with minor gaps like exact formatting of reference locations.

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 adds value by explaining include_doc_comment semantics (orphaned comments) and the diff response tied to show_write_diff, enriching beyond the schema's parameter descriptions without repeating them.

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 clearly states the tool's function: 'Delete a symbol's declaration only if it has no remaining references.' This is a specific verb+resource+condition that immediately distinguishes it from sibling tools like rename_symbol or move_symbol.

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

Usage Guidelines4/5

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

The description provides clear context: it checks references first and rejects deletion if any exist, preventing accidental removal of used code. It does not explicitly name alternatives, but the behavior is clearly scoped to safe deletion, which is enough to guide appropriate use.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/plumbkit/plumb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server