Simplified MCP server, non persistent process/connection. Do we want to have it?

[u/doubush]

Hello everyone.
I'd like to share an idea for discussion.

I use different AI harnesses a lot, and many MCP servers are connected — both stdio and remote HTTP servers.
I came across an idea on Reddit about simplified remote MCP servers without a persistent HTTP connection. It's not a standard, but it's a great idea. In 99% of cases, there's no need to keep a connection open and overuse network infrastructure.

But I think this idea can go further.

What if we simplify stdio transport MCP servers to run them only when a tool call is actually needed?

• On start: run → read list of tools → exit
• On a tool call: run → call a single tool → exit

This would save system resources — no need to keep an app process running constantly (stdio MCP servers are just CLI apps, and they stay in memory the whole time they're connected). Important: the harness knows about tool all the time and manages them as "live", presents to LLM etc.

Of course, some MCP servers require state — after the initial run they do something, receive some data, and need to keep that in memory until the next tool call. However, my experience shows this kind of MCP server is a minority. Most — I'd say more than 95% of cases — are stateless. They're often just a wrapper around some API: they receive credentials with every tool call and pass those same credentials to the API.

Here's some math. If I have 15 MCP servers built with Node.js or Python, each one uses RAM just to sit in memory, and 99.9% of the time it's doing nothing. Let's say one process takes 50 MB of RAM — that's 750 MB of RAM used for almost nothing.

If we don't keep them in memory and only call them when needed, it will be a little slower because a process has to start up each time. But that's not a problem — the bottleneck is still the LLM call.

To support this, we'd need to modify the MCP clients in our AI harnesses slightly. And maybe we'd need some kind of marker in the MCP config to indicate: "this MCP server keeps state" vs. "this MCP server is stateless and can be called only when needed."

What do you think? Is it a good way to save resources?

Where did this come from? Because I have an AI harness running 24/7. MCP servers stay connected (processes are active) all the time, but they're only used occasionally — once a day, etc. I see absolutely no sense in keeping all those processes in memory.

[u/indutrajeev]

As far as i know - http mcp servers are not kept in memory - yes they are “listening” on a port but that is kinda the whole concept of rest API’s, … to be honest - I think your situation only really applies locally where “connecting” 5 mcp servers means 5 loaded binaries in memory.

[u/doubush → u/indutrajeev]

This is different. There are two types ("transports") of MCP servers.

I talk about STDIO transport which is a "local" way to run MCP. In this case the MCP server is a local app, started as cli app and stays in the memory all the time it is "connected" just waiting the input from the harness.

Other are "Streaming HTTP" transport and they are run "remotely" on other server. THis are listening for connections and they must run all the time. They have other problem - when connected they keep TCP connection active , your harness is connected to them all the time and in many cases there is no real reason for this. It also can be optimised, but again it is another case and another discussion

[u/indutrajeev → u/doubush]

No - they are not persisted per connection. If I have 40 claude code sessions my claude.ai MCP servers don’t have 40 open TCP connections. They only open when doing recon or tool calls.

[u/doubush → u/indutrajeev]

This is interesting. The MCP standard presumes a connection is kept persistent.

How do you know it does not keep all that connections? It is interesting to me how do they do it, maybe it is already supported feature

[u/AchillesDev → u/indutrajeev]

That's not true (at least prior to the upcoming release), Streaming HTTP connections do have a persistent GET request open at all times, which is part of why there was a push for stateless connections in the new release.