Every page-one result for this query hands you the same twelve lines of JSON. Add a block to a config file, name a command, restart the client, and the tools show up. That is correct, it takes about four minutes, and it is where those pages stop.
It is also written for exactly one person: you, on your laptop. The interesting part starts when the second person on your team wants the same server, and then the fifth.
What is a local MCP server, and when should you run one?
A local MCP server is a program your AI client launches as a subprocess on your own machine, exchanging messages over stdio rather than over the network. Run one when the capability is genuinely local - files, a browser, a device - or when you are the only person who needs the answer and nobody else has to see it.
If the protocol itself is new to you, what MCP actually is covers host, server, and tool in a page. MCP is an open standard, now governed under the Linux Foundation, which is why the same server config works across clients rather than being a Claude Desktop feature.
The config is table stakes
The mechanics are worth stating once so we can move past them. Hosts like Claude Desktop keep a JSON config file listing servers by name. Each entry is a command and its arguments. On startup the host runs that command, holds the process open, and reads the tool list off stdout:
{
"mcpServers": {
"studio": {
"command": "npx",
"args": ["-y", "@aioproductoscom/mcp-studio"]
}
}
}That is the whole install. No port, no token, no callback URL. The server dies when the client closes.
Here is something checkable rather than assertable. We ship a local stdio package for our own product spine, and started with no PRODUCTOS_TOKEN it runs in demo mode against a fully seeded showcase workspace - read-only subset of the tools, no account, no credentials, no signup:
npx -y @aioproductoscom/mcp@latestPoint a host at that and ask it something ordinary in your own words - "which features have the most customer requests behind them?" What comes back is typed records with ids, not a paragraph, which is the difference between a tool a model can compose with and one it has to re-read. You can verify that claim in one command instead of taking this post's word for it.
Where a local MCP server stops paying
Now the part page one skips. None of what follows is a bug in local servers. It is what "runs on your machine" means once more than one machine is involved.
It is installed per machine. There is no central install. Every person who wants the server adds a config block and gets the package pulled to their own laptop. Five people means five installs, and five chances that one of them skipped it.
It authenticates as whoever is sitting there. A local server inherits the ambient credentials of the logged-in user - their shell environment, their SSH keys, their browser session. That is convenient and it is also the reason the server cannot answer "who is asking". There are no roles because there is no identity.
Its config drifts. One person is on the version they installed in March, another pinned a tag, a third is on -y and gets whatever is latest today. Same server name in three configs, three different tool surfaces. When someone reports that the model "picked the wrong tool", you now have to ask which build they are running.
It leaves no shared audit trail. Whatever the model read or wrote through a local server happened inside one process on one laptop and is gone when it exits. For a filesystem server that is fine. For anything touching production data it means nobody can reconstruct what happened, which is the question that actually gets asked after something goes wrong.
It updates only when each person remembers to. A fix you ship is live for a colleague the next time they restart their client, if the package resolves, if they notice. There is no way to make a change take effect for everyone at once.
Gartner expects more than 40% of agentic-AI projects to be canceled by 2027, and this is the shape most of that failure takes. Nothing breaks at the demo. It breaks at the fifth install, the stale version, the question nobody can answer about what the agent did.
Local (stdio) versus remote (Streamable HTTP)
| Local (stdio) | Remote (Streamable HTTP) | |
|---|---|---|
| Install path | Config block per machine, per person | One URL, added once for everyone |
| Authenticates as | Whoever is logged into that machine | The specific person, via OAuth 2.1 + PKCE |
| Where data travels | Nowhere - stays in one local process | Over TLS to the endpoint you or a vendor operates |
| At team scale | Five people, five installs, five states | One deployment; new members inherit it |
| Audit trail | None that outlives the process | Per-call, attributable, retained |
| How it updates | Whenever each person restarts | Server-side, live for everyone at once |
Read the rows rather than the columns. Not one of them says local is worse. They say local optimizes for a single operator and remote optimizes for a group - which is why the honest question is never "which is better" but who needs the answer, and where does the data already live.
When local is genuinely the right answer
We ship a local server ourselves, on purpose, and would not move it.
AIOProductOS Studio is a free, MIT-licensed, fully-local MCP server with 14 tools that films scripted walkthroughs of your real web app into share-ready MP4 and GIF. It is local because it drives your browser and writes video files to your disk. Hosting that would mean shipping your screen to someone else's machine to get a file back - worse in every direction. Install is npx -y @aioproductoscom/mcp-studio and there is nothing else to configure.
The same logic covers four cases worth naming plainly:
Files that must not leave the machine. A filesystem or Git server reading a client's source under NDA has a much easier compliance story when the honest answer to "where did that data go" is "nowhere".
Anything driving your own screen, browser, or devices. Playwright-style servers, screen capture, local hardware. The capability is the machine.
Offline and air-gapped work. A local server on a plane still works. An endpoint does not.
No auth infrastructure to run. A remote server means OAuth, token rotation, tenancy isolation, uptime, and an audit log. If you are one person automating your own workflow, all of that is cost with no matching benefit, and stdio's "no auth needed" is a feature rather than a gap.
The failure mode is not choosing local. It is choosing local for something that was never local - pointing a stdio server at a shared production database and discovering six weeks later that five laptops have unlogged write access to it under one shared credential.
Deciding, and what changes when the team grows
The test is one question asked twice. Does the data live on this machine, and does anyone other than me need the result? Two yeses to the first and no to the second means keep it local and stop reading. A no on the first or a yes on the second means the ceiling above is already load-bearing, and you are choosing between paying for it later or moving now.
Most real setups end up mixed, which is fine. Our own spine ships both ways deliberately - the same product data reachable as a local stdio package for individuals and as a hosted endpoint with OAuth 2.1, 71 tools, and 3 interactive ui:// MCP Apps for teams who need one install, real identity, and a per-call trail. Same tools, different operating model, and the choice belongs to the buyer rather than to us.
Two things worth reading next depending on which way you land. If you are running someone else's server against a SaaS tool, connecting an AI client to Jira or Linear covers that path. If you are considering writing your own, how to build an MCP server covers the design decisions that outlast the protocol. And if the config above is right but the tools never appear in your client, why an MCP server won't connect works through the failure modes in order.