> With 81+ tools active, I see your problem.
“you’re holding it wrong” - ok, or we could make it better
Sometimes people are actually holding it wrong though
MCP server that reduces Claude Code context consumption by 98%
81–90 of 119 posts
Re: MCP server that reduces Claude Code context consumption by 98%
#82As a newbie user that doesn't understand much of this but has claude pro and wants to use it
1. Can this help me? 2. How?
Thanks for sharing and building this.
Re: MCP server that reduces Claude Code context consumption by 98%
#83The hooks seem too aggressive. Blocking all curl/wget/WebFetch and funneling everything through the sandbox for 56 KB snapshots sounds great, but not for curl api.example.com/health returning 200 bytes.
Compressing 153 git commits to 107 bytes means the LLM has to write the perfect extraction script before it can see the data. So if it writes a `git log --oneline | wc -l` when you needed specific commit messages, that information is gone.
The benchmarks assume the model always writes the right summarization code, which in practice it doesn't.
Re: MCP server that reduces Claude Code context consumption by 98%
#84We do a fun variant of this for louie.ai when working with database and especially log systems -- think incident response, SRE, devops, outage investigations: instead of returning DB query results to the LLM, we create dataframes (think in-memory parquet). These directly go into responses with token-optimized summary views, including hints like "... + 1M rows", so the LLM doesn't have to drown in logs and can instead decide to drill back into the dataframe more intelligently. Less iterative query pressure on operational systems, faster & cheaper agentic reasoning iterations, and you get a nice notebook back with the interactive data views.
A curious thing about the MCP protocol is it in theory supports alternative content types like binary ones. That has made me curious about shifting much of the data side of the MCP universe from text/json to Apache Arrow, and making agentic harnesses smarter about these just as we're doing in louie.
Re: MCP server that reduces Claude Code context consumption by 98%
#85The hooks seem too aggressive. Blocking all curl/wget/WebFetch and funneling everything through the sandbox for 56 KB snapshots sounds great, but not for curl api.example.com/health returning 200 bytes. Compressing 153 git commits to 107 bytes means the LLM has to write the perfect extraction script before it can see the data. So if it writes a `git log --oneline | wc -l` when you needed specific commit messages, tha…
Agreed. I removed it.
Re: MCP server that reduces Claude Code context consumption by 98%
#86The FTS5 index approach here is right, but I'd push further: pure BM25 underperforms on tool outputs because they're a mix of structured data (JSON, tables, config) and natural language (comments, error messages, docstrings). Keyword matching falls apart on the structured half. I built a hybrid retriever for a similar problem, compressing a 15,800-file Obsidian vault into a searchable index for Claude Code. Stack is…
Would love to read a more in depth write up of this if you have the time !
I suspect the obsessive note-taker crowd on HN would appreciate it too.
Re: MCP server that reduces Claude Code context consumption by 98%
#87Not bad, but it sacrifices accuracy and there are risks of causing more hallucinations from having incomplete data or agent writing bad extraction logic. So the whole MCP assumes Claude is smart enough to write good extraction scripts AND formulate good search queries. I'm sure thing could expand in the future to something better, but information preservation is a real issue in my experience.
Re: MCP server that reduces Claude Code context consumption by 98%
#88I've been running https://github.com/rtk-ai/rtk for a week seems to be a good balance between culling out of context and not just killing everything. I've been running https://github.com/Opencode-DCP/opencode-dynamic-context-pru... in opencode as well. It seems more aggressive.
Re: MCP server that reduces Claude Code context consumption by 98%
#89On here: https://cc-context-mode.mksg.lu/#/3/0/3
> Bun auto-detected for 3–5x faster JS/TS execution
This is quite a claim, and even so, doesn't matter since the bottleneck is the LLM and not the JS interpreter. It's a nit, but little things like this just make the project look bad overall. It feels like nobody took the time to read the copy before publishing it.
More importantly, the claimed 98% context savings are noise without benchmarks of harness performance with and without "context mode".
I'm glad someone is working on this, but I just feel like this is not a serious solution to the problem.
Re: MCP server that reduces Claude Code context consumption by 98%
#90[dead]