Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Multi Edit MCP Server Rename oldFunction to newFunction across all files in src/"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives Claude the ability to perform multiple find-and-replace operations in a single tool call with guaranteed atomicity -- all edits succeed or none apply.
Built by Essential AI Solutions for Claude Code and Claude Desktop.
Claude's built-in Edit tool handles one find-and-replace per call. When renaming a variable across a file or refactoring multiple files, that means dozens of individual tool calls -- each consuming context tokens and adding latency.
Multi Edit batches them into a single call:
Without multi_edit: 105 tool calls | 15,750 tokens
With multi_edit: 21 tool calls | 7,850 tokens (-80% calls, -50% tokens)
With multi_edit_files: 6 tool calls | 4,550 tokens (-94% calls, -71% tokens)Benchmarks run on realistic scenarios (bulk rename, logging migration, cross-file refactor). See benchmarks/results/BENCHMARK-REPORT.md for full details.
Related MCP server: MCP Files
Add .mcp.json to your project root:
{
"mcpServers": {
"Multi Edit from Essential AI Solutions (essentialai.uk)": {
"command": "npx",
"args": ["-y", "@essentialai/mcp-multi-edit"]
}
}
}Restart Claude Code. Then add the included CLAUDE.md to your project root so Claude automatically prefers multi_edit over the built-in Edit tool:
## Editing Files
When making multiple edits to the same file or across multiple files,
prefer using the `multi_edit` and `multi_edit_files` MCP tools over
the built-in Edit tool. These batch edits atomically in a single call.That's it -- Claude will now use multi_edit whenever it's the right tool for the job.
Display name: Claude Code uses the key name in
mcpServersas the server's display name. You can change the key to any name you prefer.
Alternative: One-liner via CLI:
claude mcp add --transport stdio multi-edit -- npx -y @essentialai/mcp-multi-editNote: The CLI only accepts simple names (letters, numbers, hyphens, underscores). For the full branded display name, use the
.mcp.jsonapproach above.
Add to your config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"Multi Edit from Essential AI Solutions (essentialai.uk)": {
"command": "npx",
"args": ["-y", "@essentialai/mcp-multi-edit"]
}
}
}Restart Claude Desktop.
Full installation guide: docs/installation.md
multi_edit -- Single file, multiple editsBatch multiple find-and-replace operations on one file. Edits apply sequentially and atomically.
{
"file_path": "/project/src/app.ts",
"edits": [
{ "old_string": "const oldName = getValue()", "new_string": "const newName = getValue()" },
{ "old_string": "console.log", "new_string": "logger.info", "replace_all": true }
]
}Parameter | Type | Default | Description |
| string | required | Absolute path to the file |
| array | required | Find-and-replace operations (applied in order) |
| string | required | Text to find (exact match) |
| string | required | Replacement text |
| boolean |
| Replace all occurrences |
| boolean |
| Preview changes without applying |
| boolean |
| Create |
multi_edit_files -- Multiple files, one atomic operationCoordinate edits across multiple files. If any file fails, all files are rolled back automatically.
{
"files": [
{
"file_path": "/project/src/types.ts",
"edits": [
{ "old_string": "interface UserData {", "new_string": "interface UserProfile {" }
]
},
{
"file_path": "/project/src/api.ts",
"edits": [
{ "old_string": "UserData", "new_string": "UserProfile", "replace_all": true }
]
}
]
}Parameter | Type | Default | Description |
| array | required | Array of file edit operations |
| string | required | Absolute path to the file |
| array | required | Edits for this file (same format as above) |
| boolean |
| Preview changes without applying |
Full usage guide with examples: docs/usage.md
Atomic operations -- all edits succeed or none apply, no partial state
Multi-file rollback -- if any file fails, all previously changed files are restored
Dry-run preview -- see exactly what would change before committing
Automatic backups -- .bak files created before every edit (disable with backup: false)
Structured errors -- machine-readable error codes with recovery hints for automatic retry
Conflict detection -- warns when old_string matches multiple locations
Path validation -- absolute path enforcement, symlink resolution, existence checks
Code | Retryable | Description |
| Yes |
|
| Yes |
|
| Yes | Invalid input schema |
| No | File does not exist |
| No | Insufficient file permissions |
| No | Could not create backup file |
When retryable is true, Claude reads the recovery_hints in the response, adjusts the input, and retries automatically.
Troubleshooting guide: docs/troubleshooting.md
Node.js 20 or later
Claude Code or Claude Desktop
npm install # Install dependencies
npm run build # Compile TypeScript
npm test # Run 264 tests
npm run test:coverage # Coverage report (90%+)
npm run benchmark # Run benchmark suite
npm run dev # Watch modesrc/
index.ts # MCP server entry (stdio transport)
server.ts # Server factory and tool registration
tools/
multi-edit.ts # multi_edit tool handler
multi-edit-files.ts # multi_edit_files tool handler
core/
editor.ts # File editing engine (atomic read-modify-write)
validator.ts # Zod input validation schemas
reporter.ts # Result formatting and diff generation
errors.ts # Error classification and envelope creation
types/
index.ts # TypeScript type definitionsDocument | Description |
All setup options for Claude Code and Claude Desktop | |
Detailed tool reference with examples | |
Common issues and solutions | |
Version history | |
Performance measurements |
PolyForm Noncommercial License 1.0.0
Free for personal and non-commercial use. For commercial licensing, contact support@essentialai.uk.
Built by Essential AI Solutions
Perform multiple find-and-replace operations on a single file atomically. All edits succeed or none apply.
| Name | Required | Description | Default |
|---|---|---|---|
| edits | Yes | Array of edit operations (applied sequentially) | |
| backup | No | Create .bak backup file before editing (default: true) | |
| dry_run | No | Preview changes without applying (default: false) | |
| file_path | Yes | Absolute path to the file to modify | |
| include_content | No | Include final file content in response (default: false, use for verification) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the atomic nature of the operation ('All edits succeed or none apply'), which is a critical safety trait. However, it doesn't mention default backup behavior, dry-run option, or error handling, which would be useful for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no extraneous words. Every phrase earns its place, including the atomicity caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no output schema. The schema fully documents parameters, and the description adds atomicity context. However, it does not explain expected return values, error behavior (e.g., old_string not found), or the effect of default backup=true, leaving some gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters at 100% coverage, so the baseline is 3. The description does not add parameter-specific syntax or constraints beyond what the schema already provides; it only reiterates the concept of multiple find-and-replace operations, which maps to the 'edits' array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('perform'), a clear resource ('find-and-replace operations on a single file'), and explicitly scopes to a single file, which distinguishes it from the sibling tool multi_edit_files. It also states atomicity, clarifying the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context—this is for a single file—but does not mention alternatives or explicitly state when not to use it. Since it mentions 'single file', an agent can infer this is for one file at a time, but no explicit exclusion or alternative tool reference is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform coordinated edits across multiple files atomically. All file edits succeed or none apply.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Array of file edit operations | |
| backup | No | Ignored for multi-file operations (backups are always created as rollback mechanism). For single-file use multi_edit instead. | |
| dry_run | No | Preview changes without applying (default: false) | |
| include_content | No | Include final file content in response (default: false, use for verification) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It does disclose the critical atomicity property ('All file edits succeed or none apply'), which is not present in the schema. However, it omits other important behaviors such as return format on failure, permission requirements, and the fact that backups are always created (though the schema's backup field hints at this).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the key purpose. Every word earns its place; there is no redundancy or filler. It efficiently states the main action and the critical atomicity guarantee.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the rich schema, is adequate for understanding the tool's primary function. However, it leaves gaps: no explanation of return value, error behavior on failed atomic operation, or verification steps beyond include_content. For a mutation tool with no annotations and no output schema, a bit more context (e.g., explicit mention of rollback/backups) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already provides meaningful descriptions for all parameters (e.g., backup says it's ignored for multi-file, dry_run says preview, include_content says include final content). The tool description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure: "Perform coordinated edits across multiple files atomically." It clearly identifies the tool's function and distinguishes it from the sibling tool 'multi_edit' by emphasizing the multi-file aspect and atomicity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description itself does not mention alternatives, but the backup parameter description explicitly says 'For single-file use multi_edit instead,' providing a clear usage boundary. The atomicity clause also implies this is for coordinated multi-file operations where all-or-nothing behavior is desired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools are clearly differentiated by scope: multi_edit targets a single file while multi_edit_files targets multiple files. Although the names are similar, the descriptions explicitly clarify the difference, leaving little room for confusion.
Both tools follow a consistent snake_case pattern with the shared prefix 'multi_edit', and the suffix 'files' for the multi-file variant. The naming is predictable and clearly related.
With only two tools, the server feels thin for a general-purpose editor, but it is well-scoped for its specific purpose of atomic multi-edits. The count is borderline but acceptable given the narrow domain.
The server fully covers its stated purpose: atomic editing on a single file and across multiple files. No obvious operations are missing for the domain it targets.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Securely search and manage workspace context files for AI agents and teams.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/eaisdevelopment/mcp-multi-edit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server