leanrea vs REA: Does an 8 KB Skill Really Replace 207 MCP Tools?

leanrea is an 8 KB skill file that replicates most of what REA (Reverse Engineer Anything) does, without installing REA's 207-tool MCP server. In the author's own benchmark it ran 38% faster and 35% cheaper than REA while scoring 74 out of 75 against REA's 75 out of 75. Install it with npx skills add aicodeking/leanrea.

If you've been anywhere near Claude Code or X this month, you've seen the REA stars chart. The repo sat under 10,000 stars on October 6, crossed 100,000 by October 12, and was past 355,000 by October 21. It's one of the fastest-growing repos in GitHub's history. So naturally, a week after REA went viral, someone looked at its 25 MB npm package and asked the obvious question: does this actually need to be this big?

That someone is a developer going by AICodeKing, and the answer they shipped on October 17 was leanrea — a single SKILL.md file, no MCP server, no 207 tool definitions, just instructions telling your agent which CLI command to run for which kind of target.

What is leanrea, exactly?

leanrea is a Claude Code (and Codex, Cursor, Gemini CLI, OpenCode) skill that teaches an agent how to reverse-engineer apps using tools that are probably already on your machine: asar, otool, nm, jadx, apktool, tshark, binwalk, sqlite3, and so on. It doesn't add a single new tool to your agent's tool list. It just tells the agent, in plain instructions, which command to reach for first depending on whether you're looking at an Electron app, a native binary, a Go executable, an APK, or a database file.

REA does the same reverse-engineering job, but it does it by standing up an MCP server with 207 tool definitions your agent has to load into context before it can do anything. That's the entire architectural difference: REA wraps the CLI tools in a protocol layer and exposes them as callable tools; leanrea just hands the agent a cheat sheet and lets it run the real commands itself through Bash.

Why does the file size matter?

Because MCP tool definitions aren't free. Every tool REA exposes gets described to the model before a single token of actual work happens, and that description eats context window on every single turn, not just the first one.

The numbers from leanrea's own README: REA ships as a 25 MB npm package with roughly 72 KB of tool documentation and 207 tool definitions weighing in around 3.35 MB. leanrea is 8 KB. Total. One file.

On an agent without lazy tool loading, that difference showed up as roughly 400,000 tokens of context overhead for REA's tool set versus about 3,500 tokens for leanrea's skill instructions, according to the project's benchmark writeup. That's not a small efficiency gain, that's the difference between an agent that starts a task already carrying a backpack full of rocks and one that doesn't.

How do the benchmark numbers actually break down?

AICodeKing ran 36 total task runs (4 tasks x 3 reps x 3 arms) on Claude Code 2.1.301 headless with Sonnet 5.5, on October 16, comparing leanrea, REA (v6.5.0, 207 tools), and no skill at all as a baseline. The tasks: analyzing a Notion Electron app's mic and meeting detection, inspecting a native mac_utils.node binary for its exports and TCC checks, mapping the gh CLI's Go dependency tree, and a deeper disassembly task on that same native binary to recover its socket protocol.

leanrea beat REA on every efficiency number and landed one point behind it on accuracy, with that single miss being a case where it named an older IPC channel instead of a newer v2 one that also existed in the codebase. Not a wrong answer exactly, just not the freshest one.

Worth saying plainly: this is a 3-repetition, single-model, single-machine benchmark run by the person who built leanrea. It's not peer reviewed, and a developer who dug into the numbers (writing as "claimed vs verified" on Dev.to) flagged exactly that: these are author-reported results that haven't been independently reproduced. The benchmark also skipped native debugger paths like Ghidra and IDA, which is precisely the kind of heavy decompilation work REA's deeper toolchain is built for. So the comparison favors leanrea's strong suit (CLI-friendly recon) and doesn't really test REA's.

leanrea vs REA: which one should you actually install?

Here's my honest read after going through both READMEs and the benchmark methodology. If most of what you do is poking at Electron apps, checking what an APK's manifest declares, or tracing network calls on a website, leanrea gets you there faster and without the setup tax. You're mostly shelling out to tools you'd run by hand anyway, and the skill just saves you from remembering the right incantation for jadx or otool -L.

If you need actual decompilation, pseudocode from a stripped binary, or Ghidra-level static analysis, REA's bundled engines are doing real work that a skill file pointing at CLI tools can't replace, because you'd need those engines installed and driven correctly regardless. REA also gives you structured, consistent evidence output across runs, which matters if you're trying to build something reproducible on top of the results rather than reading a one-off answer.

I wouldn't uninstall REA to save context tokens if you're doing serious binary work. But if you installed REA just to ask your agent "how does this Electron app handle clipboard events" once a week, you installed 207 tools to answer a question a good asar extract and a grep would've answered. leanrea is the right-sized tool for that job, and most people asking REA questions are asking that kind of question.

How do I install leanrea?

npx skills add aicodeking/leanrea

That prompts you to pick which agents to configure. A few useful variants:

npx skills add aicodeking/leanrea -g                    # install for every project, not just this one
npx skills add aicodeking/leanrea -a claude-code -y      # Claude Code only, skip prompts
npx skills update leanrea                                # pull the latest version later

Once it's in, invoke it in a session with /leanrea followed by whatever you're trying to inspect. No restart dance, no MCP config file to check, no backup of your existing settings to review. That's genuinely the whole setup, and it's the clearest practical win leanrea has over REA: REA's install touches your agent config and needs a restart before the MCP server loads, leanrea doesn't touch anything but adds a skill file.

Is leanrea actually a replacement for REA, or just a subset?

A subset, and the project is upfront about that in its own docs. leanrea works when your agent already has shell access and the underlying CLI tools (jadx, apktool, otool, whatever) are installed on the machine. It doesn't verify those tools exist, it doesn't bundle decompilation engines, and it doesn't give you the same structured evidence format REA produces. What it replaces is the MCP middle layer for the chunk of reverse-engineering work that was always just "run the right CLI command and read the output" dressed up as a tool call.

That's most of what people were actually doing with REA, based on the case studies both projects publish. But "most" isn't "all," and if you're reaching for Ghidra's decompiler regularly, you still need REA or you need to drive Ghidra yourself.

Watch

If you haven't set up REA itself yet, start with our REA installation walkthrough to see the MCP side before deciding whether to trade it for a skill file. And if you're building out a broader MCP toolchain alongside either of these, Claude Code's 2.1 focus view and how Cursor wires Google Workspace into MCP are worth a look for the bigger picture on context costs.