Skip to main content
Glama

find_replace

Search and replace text across files in a directory tree. Preview changes with dry-run before applying edits, with optional regex and glob filters.

Instructions

Grep-equivalent: find text across files with optional replacement. Search and replace text across files in a directory tree.

Defaults to dry_run=true so you can preview the diff before committing. Set dry_run=false to write changes.

When the [edits].show_write_diff config flag is on (the default), the response appends a per-file unified diff — in both preview and applied modes — for up to the first 20 changed files, with a "+N more file(s)" summary beyond that. Set show_write_diff=false to suppress it.

Skips binary files (detected via null-byte sniff of the first 8 KB). Skips files larger than max_file_bytes (50 MiB default). Honours .gitignore. Use 'glob' to limit which files to touch (e.g. ".go", "**/.md"); a glob with a literal directory prefix (e.g. "src/**/*.go") prunes sibling directories from the walk entirely. Files are processed in parallel; output is sorted by path.

For identifier refactors use rename_symbol (scope- and type-aware); find_replace is for plain-text edits (doc strings, license headers, hostnames, version strings, non-code files).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
globNoFile glob filter, e.g. '*.go' or '**/*.md'. Empty = all non-binary files.
pathNoDirectory to walk, or a single file. Absolute path, file:// URI, or workspace-relative path; defaults relative to the workspace root.
dry_runNoIf true (default), preview only; do not write files.
patternNoSearch pattern. Plain text by default; regex if use_regex=true.
dirty_okNoAllow editing files that have uncommitted changes in their git repository. Default false — the replacement is refused if any target file is dirty. Pass true to proceed anyway.
max_filesNoCap on number of files modified.
use_regexNoTreat pattern as a regular expression (Go RE2). Default false — pattern is literal text, so regex syntax such as | or \. matches itself.
replacementNoReplacement text. With regex, supports $1, $2 backreferences.
format_afterNoAfter writing changes, run the workspace formatter (gofumpt for Go, ruff format for Python) on each modified file. Formatter errors are reported as warnings and do not fail the call.
case_sensitiveNoDefault: smart-case (case-insensitive iff pattern is all lowercase).
max_file_bytesNoSkip files larger than this many bytes. Default 50 MiB.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.17.0
    • addedInput schema / properties / use_regex / description
      Added value: +"Treat pattern as a regular expression (Go RE2). Default false — pattern is literal text, so regex syntax such as | or \\. matches itself."
  2. First observedv0.16.6

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers richly. It discloses the dry_run safety default, the show_write_diff config and its per-file unified diff output with the 20-file cap and '+N more' summary, the binary-file detection via null-byte sniff of first 8 KB, the max_file_bytes skip, .gitignore honoring, glob pruning behavior, and parallel processing with sorted output. This is comprehensive operational transparency well beyond the schema.

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 front-loaded with the core purpose in the first sentence, followed by a natural progression: safety default, output format, skipping rules, and routing guidance. The prose is efficient; every sentence adds operational value. The only slight deduction is that a few details (glob pruning, parallel processing) could arguably be tightened, but the content is all high-value and nothing is wasted.

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 complex 11-parameter tool with no annotations and no output schema, the description is unusually complete. It covers the safety default (dry_run), the accepted path formats (absolute, file:// URI, or workspace-relative), the output behavior (unified diff with file cap), skip rules (binary, size, .gitignore), glob semantics, formatting behavior after writes (with failure as warnings), and tool selection. An agent has everything needed to call it correctly and predict its effects.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value beyond the schema: it explains the smart-case default behavior for case_sensitive, clarifies that replacement supports $1/$2 backreferences in regex mode, and clarifies the glob directory-prefix pruning optimization. However, it does not explicitly walk through every parameter (e.g., dirty_ok is covered in schema but not in the description prose). Given the high coverage, the added semantics push slightly above baseline but not to the top.

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 precise verb+resource: 'find text across files with optional replacement' and immediately names the directory-tree scope. It explicitly contrasts itself with rename_symbol (scope/type-aware identifier refactor vs plain-text edits), which distinguishes it from the closest sibling. The title and verb are not merely restated; the description adds operational meaning.

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?

The description is unusually explicit about usage: it states the default dry_run=true preview-first workflow, lists concrete applicability examples (doc strings, license headers, hostnames, version strings, non-code files), and names the alternative tool rename_symbol for identifier refactors. It effectively tells an agent when NOT to use this tool and which sibling to prefer.

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

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