THE MCP NOISE TAX
Abstractions have operational costs. On powerful hardware those costs disappear into the noise floor. Limited hardware makes them visible — and sometimes makes you question whether you needed the abstraction at all.
MCP itself wasn’t really the problem. The problem was that I treated MCP integrations as nearly free infrastructure. MCP became a default choice for many agent integrations, and I treated it as one too. So far, I have dropped 2 use cases of MCP adapters/plugins due to load spikes on the server. I am considering alternatives right now. In one case, the agent is using the API directly. The other case is still open.
THE INVENTREE MCP PLUGIN
I set up InvenTree to track my 3D printing manufacturing process. Mostly for handling materials (filaments), BOMs and warehouse inventory, and to provide details to accountancy on material usage. The MCP integration came as a standalone plugin that required installation and even a custom Docker image build to prevent reinstalling it at runtime after each restart.
I didn’t have much experience with out-of-the-box InvenTree and accepted the fact that the server was getting busier within a few days after restarting the main service. Until it became so busy that it was no longer available via the Web or the agent. This triggered a note in my head: I need to pay attention to it.
When I finally had a while to get back to the problem a few weeks later, my agent failed to execute a flow and reported that the service was unavailable. This was a red flag, so I immediately jumped back to my assumptions. After disabling and removing the MCP plugin, the service has been working fine for a few weeks without any restarts needed. I haven’t profiled the plugin deeply enough to identify the exact cause.
I changed the agent settings to always use the API, which is suboptimal, but at least the service is not hanging anymore. That was my first lesson that adding an MCP integration has an operational cost. It isn’t necessarily a free plugin you bolt onto an existing service.
I was not really happy with this MCP plugin anyway, because many important operations were unsupported, and therefore the agent was already using the API directly to execute necessary flows.
THE MCP PROXY
I’m running 2 agentic environments, Hermes and OpenClaw, on an old EliteDesk that sits next to my desk. It’s an old AMD A8-based machine with enough computing power and minimal power consumption for tiny 24/7 services. For the last month, my peace has been disrupted by this machine generating too much random noise.
Clearly, some repeated background activity was heating up the CPU package, so the fan started spinning faster. The temperature would go down and stabilize, only to make another 10°C jump and hit the fan again. The cycle was happening approximately 4 times per minute. The worst thing — the fan was loud enough to be heard at night. Surely, I could close the doors, but that was considered a temporary solution.
I thought the EliteDesk might deserve a repaste, and it was not a bad decision, as the old thermal paste was almost dry. But it did not solve the fan ramping problem. Something was generating spikes. After migrating the Hermes VM back to the EliteDesk node, I gave it a while and heard a familiar humming noise. So it became clear which VM was responsible for it.
Besides the Hermes gateway process, my VM was running Open WebUI and… a Python MCP proxy, which was my first attempt to connect the Hermes agent to OpenClaw agents a while ago. It was a one-way connection that worked, but taught me that this was not the right way to organize cross-agent communication. I was unaware of A2A back then and wanted a faster solution, so I picked MCP via the proxy.
Open WebUI is… a web UI. I was hoping it wasn’t the one causing CPU spikes with background processes. Therefore, keeping in mind my experience with MCP for InvenTree, I stopped the MCP proxy. And now, after all the migrations back are done, I’m sitting in silence and writing this article.
The difference was subtle: the EliteDesk running at 42–52°C and keeping the fan RPM low and barely audible, while the MCP proxy was adding around 10–12°C. Therefore, when hitting 65–68°C, the CPU fan was activated periodically, generating constant noise.
SUMMARY
Again, life taught me a lesson that limited resources are sometimes better. By requiring more attention and experimentation, they are a source of valuable lessons and findings. The new MCP looks like a really great protocol. But it wasn’t worth the noise tax I was getting.
Although MCP itself is not complex, and I built my own MCP connector within a month of it being announced by Anthropic last year, I never fell in love with it. Regarding skills, I am happier using a SKILL.md wrapper + dedicated CLI client. The CLI already provides the execution layer, while the skill tells the agent how and when to use it. MCP provides a different abstraction with proper tool discovery and structured invocation, and I understand why that is useful. I am just no longer assuming I need that abstraction by default.
The updated (2026-07-28) MCP specs look good enough to give it another try. Maybe it won’t become a love story. I hope it becomes a tool I use because it serves the purpose, not because “people smarter than me invented this and said I should use it.”
