matchu-patchu-mcp

An MCP (Model Context Protocol) server exposing matchu-patchu — the unified-diff patcher that's tolerant of form, strict about intent — as a patch tool over stdio.

Tool

patch(filePath, diff, dryRun?) — applies a unified diff to a file. Sloppy AI-generated diffs are repaired and applied atomically when the intent is unambiguous; ambiguous ones fail with a precise, typed error the calling model can act on in one step. dryRun: true reports what would change without writing.

Setup

npm i -g matchu-patchu-mcp
claude mcp add --scope user patcher -- matchu-patchu-mcp

Then restart Claude Code — MCP servers load at session startup, so the patch tool won't appear until a new session. To verify which build is serving, make any patch call (dryRun: true works) — the status line of the reply carries a version and install-time tag. (With dryRun, the patched content follows it.)

Or in any MCP client configuration:

{
  "mcpServers": {
    "patcher": { "command": "matchu-patchu-mcp" }
  }
}

Launching the installed binary keeps the startup path local: no registry lookup, no package-manager resolution, nothing that can stall while the client waits.

See the matchu-patchu README for what the patcher tolerates, fuzz scores, and when to prefer it over exact string replacement.

Updating

It updates itself. There is no hook to configure and nothing to run on a schedule.

Once connected — never during startup — the server checks for a newer release and, if there is one, stages it in a per-user store (%LOCALAPPDATA%\matchu-patchu\versions on Windows, $XDG_DATA_HOME/matchu-patchu/versions or ~/.local/share/matchu-patchu/versions elsewhere). The running session keeps serving the build it started with; the next session picks up the newer one. Any patch reply tells you where you stand — the tag on its status line names the serving version and, when one is waiting, the version that takes over next session.

What makes that safe is that an update never rewrites the file the server launches from. Each version lands in its own directory, built off to one side and renamed into place in a single indivisible step, and the launcher loads the newest one that is complete. A launch overlapping an update therefore sees the old version or the new one, never a half-written mixture — which is what an in-place upgrade of a live install produces, and why the older arrangement (a SessionStart/SessionEnd hook running npm i -g) could leave a session with no patch tool and no error to explain it. If a release ever fails to load, the launcher falls back to the previous version and then to the copy inside the package, so a bad publish costs a stale version rather than a dead session.

To pin whatever is installed and stop the checks entirely:

MATCHU_PATCHU_NO_UPDATE=1

Releases are looked up at registry.npmjs.org. On a private mirror — or behind a proxy, which the update check does not honour — point it somewhere that answers, or it will simply never find an update:

MATCHU_PATCHU_REGISTRY=https://npm.internal.example.com

npm i -g matchu-patchu-mcp@latest still works and is the way to move the installed package itself forward. Prefer a moment when no session is starting: npm replaces its own tree in place, so a launch during that window can still miss the file. That is the one window left, it is a command you type rather than something running behind you, and it is why nothing schedules it for you.

Running without installing

npx runs the server straight from the registry, which is convenient for a one-off try:

claude mcp add --scope user patcher -- npx -y matchu-patchu-mcp@latest

(-y skips npx's first-run install prompt, which would otherwise hang the server spawn; @latest re-resolves against the registry at each launch, so it auto-updates.)

That resolution sits on the startup path, and MCP clients drop a server that takes too long to start — 30 seconds in Claude Code — with nothing shown in the UI. Sessions launching at the same moment contend for npx's cache and can lose that race, in which case the patch tool silently isn't there for the whole session. The global install above has no network call to lose it on; prefer it for daily use.

Inside some pnpm workspaces it fails outright instead: npx inspects the current project's node_modules before downloading anything, and that inspection can error before the server is ever reached. pnpm dlx matchu-patchu-mcp@latest skips it.

Troubleshooting

The patch tool isn't there at all — a server that fails to start is dropped silently by most clients, so the only record is the log. In Claude Code that's the mcp-logs-patcher folder under its cache directory (%LOCALAPPDATA%\claude-cli-nodejs\Cache\<project>\ on Windows); a connection timed out after 30000ms line means the launch overran the startup budget. That is the npx form losing the race described above — switch to the global install from Setup. Raising the budget is worth doing regardless, since it applies to every server you run: "env": { "MCP_TIMEOUT": "60000" } in ~/.claude/settings.json.

Windows, MCP clients other than Claude Code — the installed binary is a .cmd shim there, not an .exe, and some clients can't spawn one directly. Claude Code handles this itself, so the Setup command needs no change; for a client that doesn't, wrap it:

{
  "mcpServers": {
    "patcher": { "command": "cmd", "args": ["/c", "matchu-patchu-mcp"] }
  }
}

License

Apache-2.0. See LICENSE and NOTICE.