Hacker News Reader

Comment by nextaccountic | Hacker News Reader

> Context Bloat: Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs. It’s like forcing someone to read the entire car’s owner’s manual when all they want to do is call car.turn_on().

MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provided by a MCP server (rather than dumping the whole thing in context), it would be better. But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else

A solution is to have the agent run a cli tool to access mcp services. That way the agent can filter the output with jq, store it in a file for analysis later, etc

View on HN

> A solution is to have the agent run a cli tool to access mcp services.

lol and why do you need mcp for that, why cant that be a classic http request then?

I use this pattern with mcp-cli, and I do that instead of a curl request for two reasons: 1) not leaking my creds into the agent session, and 2) so I can allowlist / denylist specific tools on an MCP server, which I can't do as easily if I give the agent an API token and curl.

> MCP has severe context bloat just by starting a thread

Hi, author here. The “MCP has severe context bloat” problem has already been solved with tool discovery. Modern harnesses don’t load every single tool + their descriptions into the context on load, but use tool search to discover the tools lazily when they’re needed. You can further limit this by telling the LLM exactly which tool to load, the rest will stay unloaded / invisible

> But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else

This is semi-solved as agents and harnesses get smarter. Claude Code for example does discovery in subagents. So it spawns a sub-agent with a cheaper model that explores your codebase / environment (also through MCP) and provides a summary to the parent process. So the parent won’t get hit with the raw output log

> Claude Code for example does discovery in subagents.

but this still burns tokens needlessly in the subagent. if the agent could filter the mcp output using a cli (often jq, but sometimes something else), it could be more economical

maybe anthropic wants you to burn those tokens though

At least when working with local MCP servers I solved this problem by wrapping the mcp tools inside an in-memory cache/store. Each tool output gets stored under a unique id and the id is returned with the tool output. The agent can then invoke other tools by passing the id instead of generating all the input. Adding attribute access made this pretty powerful (e.g. pass content under tool_return_xyz.some.data to tool A as parameter b). This saves token costs and is a lot faster. Granted, it only works for passing values between tools but I could imagine an additional tool to pipe stuff into the storage layer would solve this.

Reply on news.ycombinator.com