Skip to main content
Glama

Replace a symbol's body by name (write)

replace_symbol

Replace or insert code symbols by name, resolving locations via an index. Supports atomic batch edits, automatic re-indexing, and safe file snapshots.

Instructions

Write a symbol by NAME — you never re-send the old body to locate the edit. Two modes: REPLACE (name/path+line plus body) overwrites an existing definition; INSERT (after:"X" or before:"X" plus body) adds a NEW symbol next to an existing one, which is what you want for 'add a method beside the related ones' — the anchor's own span comes from the index, so after means after its closing brace, not its signature line. Insert puts body in verbatim: indent it for the file, and include a leading/trailing newline if you want a blank line. range comes from the index; the file is SNAPSHOTTED first (.slimdex/snapshots), re-indexed after, and the new line span is reported so you don't re-read to verify. Safe to mix with ordinary edit tools: if the file moved under the index, a NAME is re-resolved against a fresh parse automatically (an explicit path+line still refuses, since that coordinate is yours). Ambiguous/unknown names are refused, never guessed. body = the complete replacement definition, indented for the file. edits:[…] applies several at once (one snapshot, one re-index); the batch is refused before any write if a target is ambiguous, two edits overlap, or a file isn't writable, and a write that fails mid-batch rolls the earlier files back and says so.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoThe complete new definition, replacing the old one verbatim.
lineNoDefinition line (use with path).
nameNoSymbol to replace, resolved via the index.
pathNoFile path (use with line instead of name).
afterNoINSERT mode: add `body` as a NEW symbol immediately after this existing symbol's closing brace. Pin which occurrence with path + line when the name repeats inside one file (normal for CSS).
editsNoSeveral replacements, applied atomically. Each entry takes name, or path+line, plus body.
beforeNoINSERT mode: add `body` as a NEW symbol immediately before this existing symbol.
pathPrefixNoDisambiguate the after/before anchor when the name exists in several files.
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: the file is snapshotted before writing, re-indexed after, the new line span is reported, names are re-resolved if the file moved, and batches are atomic with rollback. It even clarifies subtle semantics like 'after' referring to the anchor's closing brace, not its signature line.

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 long but every sentence earns its place. It is front-loaded with the core message ('Write a symbol by NAME'), then logically progresses through modes, anchor semantics, formatting advice, safety behavior, and batch handling. Despite the length, it remains structured and free of fluff.

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 tool with 8 parameters, two modes, and batch capabilities, this description is remarkably complete. It covers return information (new line span), safety mechanisms (snapshots, rollback), error handling (refusals), and edge cases (file moves, duplicate names), leaving no major gap for an agent to operate correctly.

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

Parameters5/5

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

Although the schema documents all 8 parameters (100% coverage), the description adds significant meaning beyond field names: it explains the REPLACE vs INSERT modes, the role of after/before, the need for proper indentation and newlines in the body, and the atomic batch behavior of edits. This greatly enhances the agent's ability to construct valid calls.

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 opens with 'Write a symbol by NAME' and immediately differentiates two modes: REPLACE overwrites an existing definition, INSERT adds a NEW symbol. This is a clear, specific verb+resource statement that aligns with its purpose and distinguishes it from sibling read/search tools.

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 when-to-use guidance, especially for INSERT mode ('what you want for add a method beside the related ones'). It explains the distinction between REPLACE and INSERT and mentions refusal on ambiguous names. It lacks explicit exclusions or direct comparisons with alternative write tools, but the context is sufficiently clear.

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/Siddhukaushik/slimdex-mcp'

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