ByteDance merged TRAE's two apps into a single release this week: an IDE with an Agent workspace ("SOLO") on top. The announcement was a day old when we finished mounting a Model Context Protocol server into it and running the thing through every surface that can call a tool.
This is a field note, not a docs recap. Everything below is something we watched happen, on a Free account, on macOS, in one night.
Disclosure: Wallaby Token operates an OpenAI-compatible inference API, and we maintain wallaby-agent-rules, an open-source, file-based memory system for coding agents. The MCP server used here is a thin shell over that system: plain Markdown files your whole team can diff.
The 60-second mount
TRAE ships a first-class MCP settings page. The exact path:
TRAE menu → Preferences → Settings → MCP → Add → Create Manually → Raw Config (JSON), then paste:
{
"mcpServers": {
"wallaby-hello": {
"command": "python3",
"args": ["/absolute/path/to/hello_mcp.py"]
}
}
}
Any stdio MCP server works; ours was a ~130-line zero-dependency Python probe with three tools (ping, note_write, note_read). TRAE picked it up immediately: green toggle, all three tools discovered, descriptions intact.
One finding worth knowing before you start: the Free plan mounts MCP servers and runs SOLO mode. We hit no paywall at any point in this test.
Three surfaces, three different behaviors
We called the same tools from every surface TRAE offers. They are not the same:
| Surface | Tool call works? | Notes |
|---|---|---|
| IDE Chat | ✅ | Recognized the tool unprompted, real call with server timestamp returned, 12s |
| SOLO (Agent workspace) | ✅ | Wrote to the shared file via note_write; verified on disk |
| Custom agent | ✅ | The reliable surface; see the loop bug below |
The lesson: which surface you ask from changes the outcome.
The loop bug, verbatim
Ask TRAE's built-in Chat to call a read-type tool with a bare instruction like note_read, and you may hit this:
⚠️ Loop was detected in the model and the request has been interrupted. Please retry or create a new task.
We captured the agent's own reasoning at the moment it looped:
"I'll be using LS to list available tools and then Read to inspect the note_read.json file for its details."
The model wasn't calling the tool. It was treating the tool definition as a file on disk: list, read, think, repeat, until TRAE's loop guard killed it. This is a model-side misunderstanding, not an MCP failure: the server was healthy the whole time, and a write call through a different surface succeeded in the same minute.
The fix that worked for us: use a custom agent. TRAE lets you define one under Settings → Agents → Create, with its own prompt and tool selection. We created one whose prompt says, in effect: this is a tool call, not a file. Never inspect .json definitions; just invoke the tool. It passed on the first attempt, and re-ran the same read in 10 seconds versus 42 once the prompt was in the right field (the "Prompt" box, not "When to Call" — a form-field mistake we made so you don't have to).
If you hit the loop error: retry in a fresh task, name the server and tool explicitly, and say "call the tool" in words. If it still loops, move the work to a custom agent. That ended it for us.
The part that actually matters: shared memory between agents
Multi-agent setups have a boring, hard problem: two agents that can't see each other's notes aren't a team, they're two strangers in the same repo.
So we tested the minimal version. One agent called note_write ("agent-A was here"). A different custom agent then called note_read — and read back the exact line, timestamp and all:
- [2026-10-10T01:09:32] agent-A was here
One file, two agents, shared state. No database, no service: the MCP server just appends to and reads a Markdown file on disk. That is the entire mechanism, and it works.
One constraint to design around: TRAE currently notes that custom agents are "only callable by built-in Agent": custom agents can't @ each other directly yet. Orchestration flows through the built-in agent for now.
What we run on top of this
The probe above became a four-tool shell over our memory files, the same discipline we open-sourced in wallaby-agent-rules, now reachable from any MCP host:
memory_recall— load MEMORY.md + NOW.md at session startmemory_write— append one dated line, never overwritingmemory_search— substring search across the memory files, returnsfile:linememory_health— run the project's hygiene scripts and return the output
The shell is ~320 lines of standard-library Python. We're folding it into the repo; watch the repo if you want it.
A side note for anyone running agents heavily: a memory file is a fixed prefix on every call, which means it bills at cache rates on any OpenAI-compatible endpoint that supports prompt caching. Our own agents' memory prefix costs us about a tenth of list input price. Worth checking how your provider meters it. The difference between cached and not cached is real money at agent scale.
The short version
- TRAE's merged release mounts MCP servers cleanly, Free plan included
- IDE Chat and SOLO both call tools, but read-type instructions can loop the built-in chat; custom agents are the stable surface
- Two agents sharing one Markdown file through MCP works, today, with zero infrastructure
- If you want the discipline these tools serve, the memory system is already open source: dated lines, plain files, no lock-in
Tested on 2026-10-10, TRAE merged Agent+IDE release, Free plan, macOS. If a TRAE update changes any of this, the correction will be dated and logged here.