re-binary-diff
# re-binary-diff
MCP server for **read-only** binary comparison: a unified diff
between two files, and a per-section fingerprint of one file.
**Dry-run only** — the server never writes a byte to disk.
## Why
The 2026-06-05 stress test surfaced a need to compare an
original binary against a patched copy (the `Output/.../patches/`
workflow) without re-introducing the on-disk patch primitive.
`re-binary-diff` is the read-only cousin: it reports the diff,
it never applies it.
## Tools
| Tool | What it does |
|---|---|
| `check_binary_diff` | Health check — `re-binary-diff` has no system deps; always `status: OK` |
| `unified_diff` | Run `difflib.unified_diff` over the byte streams of two files (or, if too large, hash their chunks) and return a structured diff |
| `fingerprint_sections` | Return per-chunk SHA-256 + offset + size for a single file (a structural fingerprint, like `re-lief.normalize_for_diff` but at chunk granularity) |
## Install
Part of the RE-AI plugin; `./install.sh` installs the package. To
install standalone:
```bash
pip install -e ./servers/re-binary-diff
```
## Run
```bash
re-binary-diff # stdio transport (default for MCP)
python -m re_binary_diff # equivalent
```
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: a health check, a single-file fingerprint, and a two-file diff. There is no ambiguity about which tool to use for a given task.
Tool names use different patterns: 'check_binary_diff' (verb_noun), 'fingerprint_sections' (verb_noun), and 'unified_diff' (adjective_noun). The mixing of conventions reduces consistency.
With 3 tools, the server is well-scoped for binary diffing tasks. It covers the essential operations without excess, though some might argue a tool to list chunks could be merged.
The tool set covers the core workflow: fingerprint a file, compare two files, and check server status. There are minor gaps (e.g., no explicit tool to fetch specific chunks), but the provided tools are sufficient for the domain.