Skip to main content
Glama
patchloom

Patchloom

Official

batch_replace

Replace specified text across multiple files in one atomic operation, with fuzzy matching and detailed per-file change reports.

Instructions

Replace the same text across multiple files in one call. Engine staging is atomic for applied writes (all written files succeed or none change). Pattern misses are soft by default: matching files still apply and total misses appear in refused[]; set require_change=true to fail the whole batch if any file has no match. Canonical field is files (array); singular file is accepted as an alias for one path. Optional fuzzy enables similarity fallback; when exact old is absent, refuse by default unless allow_absent_old=true (#1758). JSON reports match_mode (exact/fuzzy/anchored), optional match_score, optional matched_text, match_count per change and aggregate (#1674). IMPORTANT: do NOT issue concurrent write calls targeting the same files; use execute_plan for multi-op atomicity. Example: {"files": ["Cargo.toml", "README.md"], "old": "0.1.0", "new": "0.2.0"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
newYesText to replace with. Alias `to` accepted because agents often emit that name (LLM prior).
oldYesText to find in each file. Alias `from` accepted because agents often emit that name (LLM prior).
fileNoSingle file (LLM prior). Equivalent to `files: [file]` when `files` is empty. If both are set, `files` wins. Alias `path` matches replace_text priors.
filesNoFile paths to apply the replacement to (relative to working directory). Canonical multi-file form.
fuzzyNoWhen exact match fails, try fuzzy/similarity fallback (#1668).
regexNoUse regex mode for the `old` pattern.
strictNoRoll back all writes when format/validate lifecycle steps fail.
if_existsNoIf true, silently succeed when a file does not contain the pattern instead of returning an error. Useful for idempotent batch replacements.
multilineNoEnable multiline matching (dot matches newlines in regex mode).
word_boundaryNoMatch only at word boundaries. Prevents 'SetupFile' from matching inside 'BenchSetupFile'. Auto-escapes regex metacharacters.
require_changeNoFail when a file has zero matches (fail closed). Softened when if_exists is true.
min_fuzzy_scoreNoReject fuzzy matches below this similarity floor (#1687). `None` = no floor.
allow_absent_oldNoAllow fuzzy apply when exact `old` is absent (#1758). Default false (fail closed; report best candidate without writing).
case_insensitiveNoCase-insensitive matching.
command_positionNoOnly rewrite shell command-position tokens (not arguments / longer words). Peels wrappers like sudo, timeout, busybox, flock, runuser, setsid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.32.0

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly explains atomic staging, soft pattern misses surfaced in refused[], fuzzy fallback behavior with allow_absent_old, the JSON report shape, and a strong concurrency constraint. This is far more than the schema alone would reveal.

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?

The description is dense but well organized: purpose first, then atomicity, failure mode, aliases, fuzzy behavior, output shape, concurrency warning, and example. Every sentence adds operational value, and important warnings are capitalized and highlighted. The issue-tracker references are minor and do not detract.

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 15-parameter mutation tool with no output schema and no annotations, the description covers all the high-risk behaviors: atomicity, soft failures, fuzzy matching outcomes, report fields, and concurrent-write prohibition. Since the schema comprehensively documents individual parameter semantics, no critical contextual gap remains.

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

Parameters5/5

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

The schema already covers all 15 parameters, so the baseline is 3, but the description goes beyond it by clarifying that files is canonical while singular file is an accepted alias, by explaining fuzzy fallback and allow_absent_old semantics, and by giving a concrete JSON example. This materially improves the agent's ability to construct correct calls.

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 uses a specific verb and resource: 'Replace the same text across multiple files in one call.' It clearly distinguishes this from single-file text tools and AST/structural tools by emphasizing the batch, multi-file scope. The first sentence immediately communicates what the tool does and what makes it different.

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 explicitly warns against issuing concurrent write calls to the same files and directs the agent to use execute_plan for multi-op atomicity. It also explains the soft-miss vs require_change behavior, giving the agent concrete criteria for when the batch will succeed, partially succeed, or fail.

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