mcp-recall compresses MCP tool outputs (94 KB → 3.5 KB · 96%) and stores full results in SQLite for retrieval — up to 30x more tool calls per session for heavy MCP workloads. - sakebomb/mcp-recall

Hello! I built mcp-recall to solve the problem of MCP token chewing with Claude Code (also other coding systems). I saw that MCP tool output adds up quickly. A snapshot, a large API pull, a few of those, and half an hour in your context window is full. My session started needed compaction mid-task. What stood out to me: Claude Code already offloads its built-in tools to disk, but MCP tool output just gets cut off at ~25k tokens and dropped. That was the gap I wanted to close. So mcp-recall catches MCP output before it hits the window, keeps the full copy locally in SQLite, and hands Claude a short summary instead. When it needs the details, it pulls back exactly what it needs. There is no need in re-running the tool. Coming from security, keeping it local mattered to me: nothing leaves your machine, no outside service, no real dependencies. It's deterministic too. no second model in the loop deciding what to keep. I built it for my own work, but figured it could be useful for others running long MCP sessions. If you do, I'd like to hear what tends to eat your context the most.

Really interesting idea. Curious—what was the moment that convinced you MCP context needed its own product instead of becoming another feature inside existing MCP clients?

@aryan787544 great question. I figured that because MCP means model context protocol, it would be a standard method that all clients would need universally. It could be baked into each MCP client however don't think the protocol defines that feature.

The intent was to be a collection of most used calls making the LLM calls to the MCP more deterministic.

Rather than the LLM having to figure out the correct call it uses an established call known to work.

This is more than a bandaid, it should be built into MCP itself to help save tokens.

Really interesting idea. Curious—what was the moment that convinced you MCP context needed its own product instead of becoming another feature inside existing MCP clients?

The intent was to be a collection of most used calls making the LLM calls to the MCP more deterministic.

Rather than the LLM having to figure out the correct call it uses an established call known to work.

This is more than a bandaid, it should be built into MCP itself to help save tokens.

MCP-Recall

Keeps MCP tools' output from filling your context

Keeps MCP tools' output from filling your context