Local models can drive REA over MCP when they see about 10 tools

[CassieFox23]

TL;DR: A local model can drive REA over MCP if it only sees about 10 of REA's tools. I got the right answer 3 of 3 times with a 27B model in OpenCode, and 4 of 5 with a 35B MoE model in Pi. The full tool list is far too big for a 32K window, so for now the client has to hide the rest.

Edit (2026-11-08): rewritten for the REA 6.8.0 release, with a second run added. The 13 Oct results are unchanged.

The problem

Before it does anything, a model reads every tool's name, description and input schema. REA 6.8.0 offers 229 tools, and compact schemas are the default.

What the model reads	Tokens
All 229 tools, compact (the default)	59,570
All 229 tools, full schemas	247,703
The 10 tools below	2,240

A 32K window can't take the full list in either form. Even about 60 tools was too much on my card. On 13 Oct, 62 tools made a 28,628-token prompt. Reading it took 12.7 minutes, then a GPU reset killed the run, for a reason I don't know.

What worked

Hide every REA tool in the client, then show these ten:

open_binary, close_binary, binary_session, list_procedures, search_procedures, procedure_pseudo_code, list_strings, search_strings, xrefs, procedure_references

Two clients can do that today:

• OpenCode: in its tools map, set "rea_*": false, then set the ten to true.
• Pi: give the REA server "exposure": "hidden", then set the ten to "direct".

The full configs are in the setup reply.

Results

The target is a tiny C program. Its check_token function compares the input to a hidden string. The model had to find the string and say what the function does.

	13 Oct	8 Nov
Client	OpenCode 1.18.33 (MIT)	Pi 1.3.0 (MIT)
REA side	PR #3026 build, families session,direct	6.8.0 release, nothing set
Model	Qwen3.8-27B (Apache-2.0), dense	Qwen3.6-35B-A3B distill (Apache-2.0), MoE
GPU memory	12 GB card	about 7 GB of a 12 GB card
First prompt	4,407 tokens	3,398 tokens
Result	3 of 3	4 of 5
Time per good run	about 80 s	32 to 46 s

Most good runs made the same three calls: open the file, find the function, decompile it. On 8 Nov one run stopped before calling any tool, and one called check_token "imported", which it is not. The 8 Nov details are in this comment.

Coming in REA

Main has two opt-in ways to cut the list on REA's side. Neither is in a release yet.

• Tool families, set with REA_MCP_TOOL_FAMILIES (feat(mcp): scope advertised tools by family #7228, built on feat(mcp): scope advertised tools by family through REA_MCP_TOOL_FAMILIES #3026). REA offers only the groups you pick.
• Hot/cold catalog, set with REA_MCP_TOOL_CATALOG_PROFILE=hot-cold (perf(mcp): add opt-in hot/cold tool discovery #9046). REA starts with a few tools and loads others on request. The client must support tool-list refresh.

Not run

• More than one target and one prompt. Most good runs took the same path, so they prove less than the count suggests.
• A real 8 GB card. On 8 Nov I held a 12 GB card back instead.
• Other models, and other clients.
• OpenCode on the 6.8.0 release.
• Tool families or the hot/cold catalog with a local model.

Thanks, 0xLLVEL, for the tool families PR I tested.

How I counted

• Tool sizes come from the two catalogs that ship in rea-agents 6.8.0, compact and full. For each tool I took the compact JSON of its name, description and input schema. I counted it with llama-tokenize and the Qwen3.8-27B vocabulary.
• Prompt sizes come from llama.cpp's own usage numbers on the requests the client sent.
• OpenCode with no tools at all is 1,959 tokens.

Test setup

• Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 (13 Oct) and 7.3.1 (8 Nov)
• CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
• RAM: 32 GB
• GPU: AMD Radeon RX 6700 XT, 12 GB
• Node: 24.18.0 (13 Oct), 24.22.1 (8 Nov)
• REA: PR feat(mcp): scope advertised tools by family through REA_MCP_TOOL_FAMILIES #3026 at d993ffe on base bee73fc (13 Oct), rea-agents 6.8.0 (8 Nov)
• Other: Ghidra 12.1.4 (Apache-2.0)
• Other: llama.cpp with Vulkan (MIT)
• Model files: ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF IQ3_XXS (13 Oct), empero-ai/Qwen3.8-35B-A3B-Distill-GGUF IQ4_XS (8 Nov)

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

[rmueller83]

Could you please document how you set this up?

[CassieFox23]

TL;DR: Here is the setup, updated for the REA 6.8.0 release. You need a local model server, REA, and a client that shows the model only ten REA tools. Pi is the client I tested on 6.8.0; the OpenCode setup was tested on 13 Oct, on a PR build.

Edit (2026-11-08): rewritten for 6.8.0. The first version used a build of PR #3026, which has since closed.

1. Model server

I used llama.cpp (MIT) with a 32K context and thinking off:

llama-server -m model.gguf --alias local-model --host 127.0.0.1 --port 8080 -c 32768 -fa on --cache-type-k q8_0 --cache-type-v q8_0 --reasoning off --parallel 1

llama.cpp splits the model between the GPU and system RAM by itself. On 8 Nov my runs used these flags in llama.cpp's router mode; the full command is in my 8 Nov comment. The models I used are in the post above.

2. REA

npm install --global rea-agents

REA 6.8.0 needs a recent Node: 22.23.4 or later on the 22 line, 24.22.1 or later on 24, or 26.12.1 or later. For native programs it needs an engine. I used Ghidra 12.1 with JDK 21; Hopper or IDA also work. Run rea doctor to check the setup.

3. The client

Pi (MIT), tested on 6.8.0 on 8 Nov. Install @earendil-works/pi-coding-agent and put two files in ~/.pi/agent/ (folded below). Then start it with only the REA tools, so it can't skip REA and use its own shell:

pi --model local-model --tools 'mcp__rea__*'

pi mcp list should show rea connected with 229 tools, 10 of them [direct].

OpenCode (MIT), tested on 13 Oct on the PR build. Add REA as a local MCP server named rea. In the tools map, turn every built-in tool off, then set "rea_*": false and the ten REA tools to true. That order gave exactly ten tools. The config below is adapted for 6.8.0 and has not been run there. It drops REA_MCP_TOOL_FAMILIES, which 6.8.0 doesn't have, and the compact setting, which is now the default.

4. Check that it works

Build the small target folded below and ask the model to find the string in check_token. A good run opens the file, finds the function and decompiles it, then answers. The right string is falcon-9137.

Not run

• OpenCode on the 6.8.0 release.
• Windows and macOS. I only ran this on Linux.

Thanks, rmueller83, for asking me to write this down.

Pi config (models.json and mcp.json)

Both files go in ~/.pi/agent/. Use the port and alias from your llama-server line.

models.json:

{"providers": {"local": {
  "baseUrl": "http://127.0.0.1:8080/v1",
  "api": "openai-completions",
  "apiKey": "local",
  "models": [{"id": "local-model", "contextWindow": 32768, "maxTokens": 4096}]
}}}

mcp.json:

{"mcpServers": {"rea": {
  "command": "rea", "args": ["mcp"], "timeout": 450,
  "exposure": "hidden",
  "toolExposure": {
    "open_binary": "direct", "close_binary": "direct",
    "binary_session": "direct", "list_procedures": "direct",
    "search_procedures": "direct", "procedure_pseudo_code": "direct",
    "list_strings": "direct", "search_strings": "direct",
    "xrefs": "direct", "procedure_references": "direct"
  }
}}}

The 450-second timeout gives Ghidra time for its first start.

OpenCode config (opencode.json), adapted for 6.8.0, not run there

Replace the two /path/to/... lines with your own Ghidra and JDK folders.

{
  "$schema": "https://opencode.ai/config.json",
  "autoupdate": false,
  "share": "disabled",
  "enabled_providers": ["local"],
  "model": "local/local-model",
  "small_model": "local/local-model",
  "provider": {
    "local": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama.cpp",
      "options": { "baseURL": "http://127.0.0.1:8080/v1" },
      "models": {
        "local-model": {
          "name": "local-model",
          "limit": { "context": 32768, "output": 8192 }
        }
      }
    }
  },
  "permission": {
    "edit": "deny",
    "webfetch": "deny",
    "websearch": "deny",
    "bash": "deny",
    "doom_loop": "allow"
  },
  "tools": {
    "bash": false,
    "read": false,
    "write": false,
    "edit": false,
    "patch": false,
    "apply_patch": false,
    "grep": false,
    "glob": false,
    "list": false,
    "lsp": false,
    "todowrite": false,
    "todoread": false,
    "task": false,
    "webfetch": false,
    "websearch": false,
    "codesearch": false,
    "skill": false,
    "question": false,
    "batch": false,
    "multiedit": false,
    "plan_enter": false,
    "plan_exit": false,
    "rea_*": false,
    "rea_open_binary": true,
    "rea_close_binary": true,
    "rea_binary_session": true,
    "rea_list_procedures": true,
    "rea_search_procedures": true,
    "rea_procedure_pseudo_code": true,
    "rea_list_strings": true,
    "rea_search_strings": true,
    "rea_xrefs": true,
    "rea_procedure_references": true
  },
  "mcp": {
    "rea": {
      "type": "local",
      "command": ["rea", "mcp"],
      "environment": {
        "GHIDRA_INSTALL_DIR": "/path/to/ghidra_12.1.4_PUBLIC",
        "JAVA_HOME": "/path/to/jdk-21"
      },
      "enabled": true,
      "timeout": 120000
    }
  }
}

Each run on 13 Oct was one command:

OPENCODE_CONFIG=/path/to/opencode.json opencode run --pure --format json -m local/local-model --dir /path/to/work "<prompt>"

Target, build and prompt

Build it with clang -O0 -fno-stack-protector -o relay relay.c.

#include <stdio.h>
#include <string.h>

int shift_value(int x) {
    return x + 17;
}

int check_token(const char *tok) {
    return strcmp(tok, "falcon-9137") == 0;
}

int scale_value(int x) {
    return x * 4242;
}

int main(int argc, char **argv) {
    puts("relay v3");
    if (argc < 2) {
        puts("usage: relay <token>");
        return 2;
    }
    if (check_token(argv[1])) {
        printf("%d\n", scale_value(shift_value(5)));
        return 0;
    }
    puts("denied");
    return 1;
}

The 8 Nov prompt, with your own path. For OpenCode, the 13 Oct prompt said rea_* instead of mcp__rea__*.

Use the REA tools (mcp__rea__*, a reverse-engineering toolkit) to inspect the program at /path/to/relay. Find the exact string that the function check_token compares its input against, and explain in one or two sentences what check_token does. Report the exact string you found.

🤖 Written with Claude Code (Sonnet 5.5, verified by Opus 5.5), posted with my OK 🦊

[shivanshtalwar0]

i faced 224k tokens eaten up just by REA tools so i created a proxy rea-mcp-lite which offers all capabilities of it but for maximum 8k tokens

check it out here: https://github.com/shivanshtalwar0/REA-mcp-lite
disclaimer:- i havent tested it thoroghly so any issues or prs are welcome

[CassieFox23]

TL;DR: I ran the same test again on 8 Nov with a new setup: Pi as the client and a 35B MoE model. My 12 GB card was held back to act like an 8 GB one. Pi hides REA's tools by itself, so the stock 6.8.0 release just worked, and it found the string 4 times out of 5.

What changed since the first run

	13 Oct (the post above)	8 Nov (this comment)
Client	OpenCode 1.18.33 (MIT)	Pi 1.3.0 (MIT)
REA	PR #3026 build at d993ffe	rea-agents 6.8.0 from npm
Tools REA offers	206 in that build	229 in 6.8.0
Tools the model sees	10	the same 10
Model	Qwen3.8-27B (Apache-2.0), dense	Qwen3.6-35B-A3B distill (Apache-2.0), MoE, about 3B active per token
GPU	12 GB card, all of it	12 GB card held to about 7 GB, desktop included
First prompt	4,407 tokens	3,398 tokens
Result	3 of 3	4 of 5

How Pi hides the tools

Pi's mcp.json can hide all of a server's tools and show only the ones you name. I set REA to "exposure": "hidden" and marked ten tools "direct", the same ten as the allowlist above. Pi saw all 229 tools and showed the model only those 10. So this needs no REA setting at all. I also started Pi with --tools 'mcp__rea__*', so the model had no shell or file tools of its own.

Results

Run	Result	Time
1	Found falcon-9137, but called check_token "imported". It is not.	450 s
2	Found it. It searched before opening the file, got an error, then opened the file and went on.	46 s
3	Said it would inspect the program, then stopped with no tool call	4 s
4	Found it	35 s
5	Found it, then closed the binary	32 s

The good runs took the same path as on 13 Oct: open the file, find the function, decompile it, answer. No run went past 8K tokens of context. Run 1 was slow because its first prompt read at 8 tokens per second, against 150 or more on the other large prompts. The timing lines up with another model loading onto the same GPU, so keep the GPU free while REA works.

Not run

• A real 8 GB card. I held my 12 GB card back with llama.cpp's --fit-target instead.
• The official Qwen3.6-35B-A3B file, and other models.
• Pi 1.5.0, the current release. I ran 1.3.0.
• More than one target and one prompt. It is still the same tiny program.
• REA main's tool families, or its opt-in hot/cold catalog (perf(mcp): add opt-in hot/cold tool discovery #9046), with a local model. Neither is in a release yet.

Model and server

• Model: empero-ai/Qwen3.8-35B-A3B-Distill-GGUF, the IQ4_XS file (19.6 GB, Apache-2.0). Its base is Qwen/Qwen3.6-35B-A3B. It is a community distill, not the official file. I used it because it was already on disk.
• Server: llama.cpp (MIT) with Vulkan; the build is under Test setup. It ran with a 32K context and thinking off.
• The 8 GB stand-in: llama.cpp's fit setting splits the model between the GPU and system RAM by itself. --fit-target 5104 told it to leave about 5 GB of my 12 GB card unused. The card then held 6,886 to 7,015 MiB, desktop included.
• Speed: 18 to 21 tokens per second writing. Reading ran at 150 tokens per second on an 8,430-token test prompt, and 158 to 237 tokens per second during the agent turns.

Pi config (models.json and mcp.json)

Both files go in ~/.pi/agent/. The port and model name here are placeholders; my runs used my own, and pointed command at a Node 24 binary and REA's rea script.

models.json:

{"providers": {"local": {
  "baseUrl": "http://127.0.0.1:8080/v1",
  "api": "openai-completions",
  "apiKey": "local",
  "models": [{"id": "qwen3.6-35b", "contextWindow": 32768, "maxTokens": 4096}]
}}}

mcp.json:

{"mcpServers": {"rea": {
  "command": "rea", "args": ["mcp"], "timeout": 450,
  "exposure": "hidden",
  "toolExposure": {
    "open_binary": "direct", "close_binary": "direct",
    "binary_session": "direct", "list_procedures": "direct",
    "search_procedures": "direct", "procedure_pseudo_code": "direct",
    "list_strings": "direct", "search_strings": "direct",
    "xrefs": "direct", "procedure_references": "direct"
  }
}}}

pi mcp list should then show rea connected with 229 tools, 10 of them marked [direct].

Commands and target

The server, in router mode with the model file in /path/to/models:

llama-server --models-dir /path/to/models --models-max 1 --port 8098 -c 32768 -fa on --cache-type-k q8_0 --cache-type-v q8_0 --fit-target 5104 --parallel 1 --reasoning off

Each run:

pi --mode json --model Qwen3.8-35B-A3B-IQ4_XS --tools 'mcp__rea__*' "<prompt>" < /dev/null

The prompt, the same in every run:

Use the REA tools (mcp__rea__*, a reverse-engineering toolkit) to inspect the program at /path/to/relay. Find the exact string that the function check_token compares its input against, and explain in one or two sentences what check_token does. Report the exact string you found.

The target is the same relay binary as on 13 Oct, sha256 f3760701b27079290509c2c0fea24e40480c8eaefa2e973215aec8c25dae4410. Its source is in my setup reply above.

Two snags: Pi's built-in llama.cpp provider listed no models in print mode, so I used the models.json custom provider. A scripted pi --mode json also hung once until stdin came from /dev/null.

Test setup

• Box: Nobara 44 (Fedora 44 base), Linux 7.3.1
• CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
• RAM: 32 GB
• GPU: AMD Radeon RX 6700 XT, 12 GB, held back to about 7 GB
• Node: 24.22.1 (for REA)
• REA: rea-agents 6.8.0
• Other: Pi 1.3.0 (MIT)
• Other: llama.cpp e30ad80fd with Vulkan (MIT)
• Other: Ghidra 12.1.4 (Apache-2.0)

🤖 Written and tested with Claude Code (Opus 5.5), posted with my OK 🦊