Skip to main content
Glama
j0hanz

filesystem-mcp

by j0hanz

Search and Replace

replace_text
Destructive

Search and replace text across multiple files using glob patterns. Replace all occurrences per file, with optional regex, dry-run preview, and unified diff output.

Instructions

Bulk search-and-replace across files matching a glob pattern. Replaces ALL occurrences per file (unlike edit, which replaces only the first match). Set returnDiff=true to preview changes as a unified diff before or after writing. Literal matching by default; set isRegex=true to enable RE2 regex with capture groups ($1, $2).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoFile to rewrite, or directory to rewrite under. Omitting it targets the ENTIRE first allowed root — scope it deliberately, and pair a wide scope with dryRun=true first
dryRunNoPreview replacements without writing to disk (default: false = apply changes)
isRegexNoTreat searchPattern as a RE2 regex (default: literal text match)
patternNoGlob to restrict replacements to specific file types (e.g. **/*.ts); default: all text files
maxDepthNoMax directory depth to scan; 0 = base directory only, omit for unlimited
maxFilesNoMaximum number of files to process
wholeWordNoMatch whole words only (word boundary anchoring)
maxResultsNoMaximum total match count across all files before stopping
returnDiffNoInclude a unified diff of all changes in the response
replacementYesReplacement text. Use capture group references ($1, $2, etc.) when isRegex=true. Use an empty string to delete all matches.
caseSensitiveNoEnable case-sensitive matching (default: case-insensitive)
includeHiddenNoInclude hidden items (starting with .)
searchPatternYesExact literal text or RE2 regex pattern to search for. When isRegex=true, uses RE2 syntax (no lookahead, lookbehind, or backreferences are supported). Cannot be empty or whitespace-only.
includeIgnoredNoInclude ignored items (node_modules, .git, etc).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNoUnified diff of all changes (present when returnDiff=true or dryRun=true)
resultsYesPer-file results: modified files, then any that could not be processed
summaryYes
filesScannedYesTotal number of files examined
totalMatchesYesTotal number of replacements made across all files
diffTruncatedNoTrue when the diff was cut due to the size limit
stoppedReasonNoWhy enumeration stopped early: maxResults = match cap reached, maxFiles = file cap reached, timeout = time limit hit or cancelled. Absent when every matching file was enumerated. Marks the sweep incomplete, not the writes; files already dispatched still complete.
resultsTruncatedNoTrue when the results list holds fewer entries than summary.total: the changed-file or failed-file cap was hit. Trust summary over results.length.
Install Server

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare `destructiveHint: true`, and the description strengthens this by stating that replacements are written and that `returnDiff` can preview changes before or after writing. It also discloses default literal matching and RE2 regex behavior. It could add more about dry-run usage, but the description already goes beyond the annotations usefully.

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?

Three compact sentences front-load the core purpose, the key distinction from `edit`, the preview mechanism, and the regex/literal behavior. Every sentence contributes meaning and there is no redundant restatement of schema or annotations.

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?

For a destructive bulk-operation tool with 14 parameters, the description efficiently covers the essential decision points and safety mechanism. The comprehensive schema and output schema cover the remaining parameters and return shape. A direct mention of `dryRun` in the description would make it slightly more complete, but the existing guidance via `returnDiff` and the `path` schema is strong.

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 schema already documents all parameters. The description adds value by explaining tool-level semantics: literal vs. regex matching, capture-group references, all-occurrence replacement, and diff previews. This clarifies how the core parameters interact without replacing 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?

The description clearly identifies the action ('Bulk search-and-replace'), the resource ('files matching a glob pattern'), and the key behavioral scope ('Replaces ALL occurrences per file'). It also explicitly contrasts itself with the sibling `edit`, so an agent immediately knows how this tool differs.

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 provides an explicit alternative and the deciding condition: use this tool for all occurrences, whereas `edit` replaces only the first match. It also gives concrete guidance on when to enable `returnDiff` for previewing changes, helping agents choose safe invocation patterns.

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

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/j0hanz/filesystem-mcp'

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