Can You Keep MCP Entirely on Your Own Machine? I Counted 2,500 Servers | MCP Part 3

2026年8月15日

I run AI on my own machine less because it is fast or cheap and more because I would rather my data did not leave. If I go to the trouble of running things locally and then an extension ships everything off to somebody else’s server, most of the point is gone.

MCP (Model Context Protocol) servers come in two kinds: those that run here, and those that run on someone else’s machine. They feel almost identical to use, and what happens inside is completely different.

Can you actually close the loop locally with MCP as it stands? I pulled 2,500 records from the official registry and counted how many of each kind there are.

This is where things stood in July 2026. For the specification I am referring to the latest revision, 2026-07-28.

The previous article in this series:

Are There Really Over 9,000 MCP Servers? Sorting Them by What You Actually Want

I set out to try MCP (Model Context Protocol), looked at the list of published servers, and stop ...

 https://kimono-oyaji.com/en/how-many-mcp-servers-part2-en/

The aim: telling two identical-looking things apart, with numbers

Adding an MCP server means writing a few lines of configuration. Local and remote take about the same effort to write. Which is exactly how you end up connected to something outside without having thought about it.

Two things I wanted from this part. One is to lay out the difference. The other is to actually count the current ratio. Turning a feeling into a number changes how you choose next time.

Where the two kinds differ

The naming wanders between documents, but underneath it is simply “where does the program run."

In the terminology, local appears as stdio (standard input/output) and remote as streamable-http or sse. Spot those words in a configuration file and you know which kind you are looking at.

Note that sse is the older approach, and the 2026-07-28 specification formally classified it as deprecated. Find that word in a configuration and you can read it as: this server has not moved to the new approach.

What I did: pull 2,500 records from the official registry and classify them

The official MCP registry publishes its data in a form anyone can fetch. I pulled 100 at a time, 25 times, for 2,500 records.

The classification rule is simple. Each record has “packages" and “remotes" fields: a package means something you install and run here, a remote means something you connect out to. Some have both.

These were taken from the top in registration order, so they are not necessarily representative of everything. Read it as the shape of those 2,500.

Result: 70% were remote

Counting it surprised me, frankly. I had assumed running things locally was the mainstream. It is the other way round.

The breakdown of distribution methods and transports came out too.

Why remote grew

Put yourself in the publisher’s position and several reasons suggest themselves.

First, your users install nothing. A local server needs the user to have Node.js or Python set up, and people drop out at that step. With remote, they write a URL.

Second, the publisher can swap out the internals. Bug fixes and new features do not require the user to update anything.

And if you are offering it as a business, having usage visible on your side is presumably convenient. In the data I pulled, plenty were existing services that had simply added a connection point.

The transport split — 2,080 on streamable-http against 96 on sse — backs the same trend. And this reading later got confirmation from the specification itself.

A revision the day before changed what these numbers mean

Looking over the totals I noticed that the MCP specification had been substantially revised on 28 July 2026, the day before I pulled the data. That revision changes how the 71.4% above should be read.

What changed is that staying connected is no longer assumed. Until now a remote server had to remember who it was talking to via a tag called Mcp-Session-Id. That tag, and the opening greeting (initialize), have been removed; each request now carries what it needs.

What does that mean in practice? Once there is nothing to remember, a server no longer has to stay running. It can be built to start when a request arrives, answer, and disappear. Which is to say it can sit on the cheap, thin places — serverless and edge platforms.

One qualification. This revision is sometimes described as “everything finishes in a single exchange," but it is not that simple. Long-lived connections for receiving notifications, and mechanisms that assume several exchanges, both remain in the specification. Nor did the things worth remembering disappear — they moved into the request, as a tag the server issued. The exchange did not vanish; it moved is the accurate reading.

Nor did resilience improve. The mechanism for resuming an interrupted connection was removed in this revision. If it breaks, the request in flight is lost and the rule is to reissue it under a new number. Fewer reconnections, but harsher handling when one does drop.

What to look at if you want to stay local

70% remote also means choosing without thinking will probably connect you outward. Keeping it local takes a deliberate choice.

You tell them apart by what goes in the configuration. If it launches a command (there is a command entry), it is local; if it points at a URL, it is remote. The former came mostly from npm or PyPI.

Pairing it with a local LLM

Combine a local LLM with a local MCP server and, in principle, you have a setup where nothing leaves. Trying it, it does run — but whether the model handles tool calls well depends on the model.

In my setup, handing over fewer tools tended to be more stable. Three tools rather than ten and it picks the one you meant more often. I would like to measure this properly, including how it differs between models.

One more change from the 28 July revision belongs here. The sampling mechanism has been deprecated. That was how an MCP server could ask “may I borrow your AI for a moment" — the route for letting a server use the model on your own machine. The official migration path given is “connect directly to your LLM provider’s API."

From the keep-it-local position, that is a shame. That said, a local LLM can be called as an API on localhost, so rewriting the server to call that API directly keeps the closed setup intact. It is more work, not a closed door. Deprecated features are specified to remain for at least 12 months, so there is no need to rush a rewrite either.

Wrap-up: convenience is bought by choosing who receives your data

• Counting 2,500 records in the official registry: remote only 71.4%, local only 15.3%, both 12.0%
• Remote is common presumably because users install nothing and publishers can swap the internals
• Local distribution is mostly npm 565 / PyPI 269. Remote transport is dominated by streamable-http at 2,080
• To stay local you have to choose deliberately. A URL in the configuration means remote
• Even a local server sends data out if it calls an external service inside. “Runs here" and “stays here" are different claims
• The specification was revised the day before the data pull (28 July 2026) and dropped the always-connected model. Nothing has to stay running, which is a tailwind for remote. The 70% looks more likely to grow
• The older transport (sse) is now classified as deprecated. 96 records in this count use it
• Sampling is deprecated too. The route for lending your local model to a server has narrowed, but calling the localhost API directly keeps a closed setup possible

Across these three parts we have covered what MCP is, how many there are, and which kind you end up choosing. If you care about running things on your own machine, paying attention at the choosing stage saves trouble later.

Hardware used

The machines used to pull the data and to check the pairing with a local LLM.

As an Amazon Associate we earn from qualifying purchases.

Sources

Checked 30 July 2026 (data pulled 29 July). Specification referenced: 2026-07-28 (current). Registry counts and ratios move daily.