Skip to main content
Glama

Modify Files

synapse_modify_files

Preview and apply atomic file writes with lint checks and automatic rollback, or run global regex find-and-replace across the codebase files.

Instructions

Modifies files in the workspace. For safe agent workflows, first call 'write_safely' with dry_run: true, pre_check: true, and lint: true; review the preview, then call again with dry_run: false only when applying. High-level actions include:

  • 'write_safely': writes content with atomic lint validation, dry-run semantic diff simulation, pre_check blast radius mapping, and automatic rollback on failure.

  • 'find_and_replace': runs global regex find-and-replace across matching indexed files with instant re-indexing.

  • 'delete_chunk': removes a chunk from the index.

REPLACES: write_to_file, replace_file_content, multi_replace_file_content, manual lint + commit cycles. Use this tool instead of these alternatives for better results with 30-60% fewer tokens via automatic compression.

Usage (short): Preview and apply atomic safe file writes, global find-and-replace, or delete chunks.

Usage (long): Write files safely with automatic lint checks and revert on failure, run workspace-wide find and replace, or purge chunk entries. Always call synapse_get_context (edit) before this tool to understand callers, callees, and tests. For write_safely, first call with dry_run: true, pre_check: true, and lint: true so the agent sees semantic safety, compilation errors, contract warnings, and blast radius without touching disk. Apply with dry_run: false only after reviewing that preview. Validates with Trunk linter — rolls back atomically on lint failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoFilter by entity kind (used in 'find_and_replace').
lintNoSet false to bypass Trunk validation and write unconditionally (used in 'write_safely').
pathNoFilter by partial file path (used in 'find_and_replace').
filesNoList of file write operations (used in 'write_safely'). Each entry requires path and mode.
limitNoMax number of files to modify (safety limit, 1-100, used in 'find_and_replace').
queryNoThe PCRE regular expression to search for (used in 'find_and_replace').
actionYesThe modification action to perform.
dry_runNoAlways set true first to perform a semantic simulation of the proposed changes without writing to disk (used in 'write_safely'). Set false only after reviewing the preview and deciding to apply.
repo_idNoRepository ID to resolve relative paths or scope filters.
chunk_idNoThe chunk ID to permanently delete (used in 'delete_chunk').
languageNoFilter by language (used in 'find_and_replace').
pre_checkNoSet true to run a blast radius analysis before writing (used in 'write_safely').
max_tokensNoApproximate final response budget in tokens (500-32000, default 4000).
replacementNoThe replacement string. Supports backreferences like \1, \2, etc (used in 'find_and_replace').
case_insensitiveNoSet to true to ignore case (used in 'find_and_replace').
compress_payloadNoSet false to disable lossless response-key compression.
wait_for_ready_msNoOptional timeout in ms to wait for the indexer to finish warming up and enter an idle state before executing. Use to ensure stable results.
Behavior5/5

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

With no annotations available, the description carries full disclosure burden and does so thoroughly. It reveals atomic lint validation, dry-run semantic simulation, blast radius mapping, rollback on lint failure, permanent chunk deletion, re-indexing, and the fact that dry_run: true never touches disk.

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 long, but the tool is complex and 17 parameters; bullets and separate Usage sections keep it scanable. There is some repeated safe dry-run guidance across the intro and long usage, preventing a perfect score.

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 no-annotation tool with no output schema, this description is unusually complete: safe workflow, action semantics, lint/rollback behavior, compression, and the required preceding call to get_conext are all present. An agent can safely invoke first dry-run and decide whether to apply.

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 the baseline is already strong; the description adds the phase-driven semantics of dry_run/pre_check/lint and groups filters for find_and_replace. It does not describe every parameter, but it does meaningfully bind the most safety-critical and action-specific properties.

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 a clear resource and scope ('files in the workspace') and then enumerates the three concrete actions: write_safely, find_and_replace, and delete_chunk. It also explicitly names the alternatives it replaces, so an agent can distinguish this tool from legacy or sibling editing tools without opening the 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?

It gives a concrete safe workflow: call write_safely with dry_run, pre_check, lint true, review preview, then call apply with dry_run false. It also names a necessary preceding tool (synapse_get_context) and states when this tool should replace common alternative tools.

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/myelixlabs/synapse-mcp'

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