Skip to main content
Glama
patchloom

Patchloom

Official
by patchloom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

apply_patch

Destructive

Apply unified diffs, Codex patches, or Aider SEARCH/REPLACE blocks to edit files. Preview changes without writing, or write and handle stale context/conflicts.

Instructions

Apply a unified diff, a Codex *** Begin Patch document, or an Aider SEARCH/REPLACE / DiffFenced document. Default apply=true writes (same as CLI patch apply --apply). Set apply=false for check-only preview (CLI patch check; disk is unchanged). The diff parameter is the full unified diff text, a *** Begin Patch ... *** End Patch envelope (Add/Update/Delete/Move), or <<<<<<< SEARCH / ======= / >>>>>>> REPLACE blocks (dest path above ------- after SEARCH). SEARCH/REPLACE is unique by default (multi-match is ambiguous, no write); set replace_all=true to update every exact match. Empty-hunk +++ /dev/null (git deleted file mode, no hunks) unlinks. A hunked delete applies minus lines first; leftover bytes rewrite the file (preview --diff). Stale minus lines are ambiguous and the file is not removed; regenerate minus lines or use file.delete for path-only unlink. Use on_stale=merge for three-way merge on stale unified-diff context; allow_conflicts=true writes conflict markers. Never commit files containing conflict markers. Example: {"diff": "--- a/file.txt\n+++ b/file.txt\n@@ -1 +1 @@\n-old\n+new", "on_stale": "fail"}

Input Schema

NameRequiredDescriptionDefault
diffYes
applyNoWhen true (default), apply the patch. Set `apply=false` for check-only preview (CLI `patch check`; disk is unchanged).
strictNoRoll back all writes when format/validate lifecycle steps fail.
on_staleNofail
replace_allNoSEARCH/REPLACE only: update every exact match. Default unique.
allow_conflictsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.32.6
    • addedInput schema / properties / apply
      Added value: +{
+  "default": true,
+  "description": "When true (default), apply the patch. Set `apply=false` for check-only\npreview (CLI `patch check`; disk is unchanged).",
+  "type": "boolean"
+}
  2. First observedv0.32.0

TDQS

A4.2/5.0
Behavior5/5

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

Well beyond the destructiveHint=true annotation, it discloses that multi-match SEARCH/REPLACE is ambiguous and results in no write, that empty-hunk /dev/null unlinks, that stale minus lines leave the file untouched, that allow_conflicts writes conflict markers, and warns never to commit conflict-marker files. This is unusually rich behavioral disclosure for a mutation tool.

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?

Front-loads the core action and each clause carries real information, so virtually nothing is wasted. However it is delivered as a single dense run-on paragraph full of semicolons and jargon, which costs some readability for a complex tool.

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?

Covers formats, default write behavior, edge cases (stale context, empty-hunk unlink, conflict markers), and recovery advice, which is substantial for a destructive tool with no output schema. Return values/result reporting are not described, and 'strict' is unexplained, leaving minor gaps.

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?

With only 50% schema description coverage, the description compensates by explaining the diff formats in depth, apply's default and preview semantics, replace_all's uniqueness rule, on_stale=merge, and allow_conflicts=true. Only the 'strict' parameter (rollback on lifecycle failure) is left to the schema, so it nearly closes the coverage gap.

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?

States a precise verb ('Apply') and enumerates the resource/input forms it accepts: unified diff, Codex *** Begin Patch, and Aider SEARCH/REPLACE. This is specific and unambiguous, but it never names or contrasts with siblings such as apply_fragment, replace_text, or batch_replace, so sibling differentiation is left implicit.

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

Usage Guidelines4/5

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

Provides clear in-tool routing: apply=true writes vs apply=false is check-only, on_stale=merge for three-way merges, replace_all for multi-match, and explicitly recommends file.delete for path-only unlink. There is no high-level statement of when to pick this tool over the sibling patch/replace tools, which keeps it short of a 5.

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

Deploy Server

Other Tools