Skip to main content
Glama

Batch Replace

batch_replace

Search and replace exact text across multiple files matched by a glob pattern, with a configurable safety cap on modified files.

Instructions

Search and replace a string across multiple files matching a glob pattern.

Input Schema

NameRequiredDescriptionDefault
patternYesGlob pattern matching files (e.g. 'src/**/*.py', '*.ts').
max_filesNoSafety cap on modified files.
root_pathNoBase directory for search..
new_stringYesReplacement text.
old_stringYesExact text to search for.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden for a bulk mutation tool. It does not disclose whether replacements are atomic, what happens on partial failure, whether changes are reversible, or that files are overwritten in place; the max_files safety cap exists only in the schema, not the description.

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?

A single front-loaded sentence with no wasted wording, and the glob-scoping qualifier is placed where it matters. Its brevity is efficient, though it edges toward under-specification for a destructive multi-file operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the input schema fully documents all five parameters. What is missing for a bulk mutation with zero annotations is risk and failure context, which leaves the definition only minimally complete for this complexity level.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including pattern, old_string, new_string, max_files and root_path is already documented in the schema. The description adds no further parameter meaning, such as case sensitivity or whether old_string matches exactly one occurrence per file, so it sits at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb pair ('search and replace') and a resource ('a string across multiple files'), plus the scoping mechanism ('matching a glob pattern'). It is clearly distinguishable from edit_file/write_file by the multi-file, pattern-driven nature, though it never names the single-file alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Bulk multi-file scope is implied by 'across multiple files matching a glob pattern', which lets an agent infer this is the bulk variant rather than a single-edit tool. However, there is no explicit when-to-use/when-not guidance, no mention of the single-file sibling edit_file, and no prerequisites such as confirming changes are wanted.

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