Self-hosted vs managed MCP servers for personal agents
The real difference between a managed and a self-hosted MCP server is where your tokens sit when nobody is using them. There is also a third option most comparisons leave out.
DevRel Engineer
You want your personal agent to reach your email, your notes and your files. MCP is how you connect those, and you have a choice about where the server runs.
Where does your refresh token sit overnight? Who can read the logs? What happens if the company running it is breached?
Those three questions separate the options better than any feature list. Start there and the choice gets simple.
There are three models, not two
Managed. A vendor runs the MCP server. You sign in to their site, grant access to your accounts, and point your agent at their URL. Your tokens live in their database.
Self-hosted remote. You run the same kind of server yourself, on a VPS or a home machine, reachable over the network. Your tokens live in your database. You also run the updates.
Local stdio. The server runs as a process on the machine you are working on, and your agent talks to it over standard input and output. There is no port, no URL and no inbound connection at all.
Most comparisons cover the first two and skip the third. For a personal agent the third is often the best answer, so it gets the most space here.
| Managed | Self-hosted remote | Local stdio | |
|---|---|---|---|
| Tokens at rest | Vendor's database | Your server | Your machine |
| Network listener | Vendor's, public | Yours, public or VPN | None |
| Who sees request logs | Vendor and you | You | You |
| You patch it | No | Yes | Yes, by updating a package |
| Works away from your desk | Yes | Yes | No |
| Breach of the vendor affects you | Yes | No | No |
Why local stdio is underrated
A remote MCP server needs authentication, because it listens on a network. That means it holds credentials for your accounts and a way for clients to prove who they are. Both are attack surface, and both exist all the time, including while you sleep.
A stdio server has none of that. Your client launches it as a child process when you start work. It reads and writes on a pipe. When you quit, the process exits. Nothing is listening, so there is nothing to scan for and nothing to brute force.
Claude Desktop, Claude Code, Cursor and most other clients support this. The configuration is a command, not a URL.
{
"mcpServers": {
"swytchcode": {
"command": "npx",
"args": ["-y", "swytchcode", "mcp"]
}
}
}No endpoint, no shared secret, no inbound rule in your firewall. Per-client setup for the other editors is in the MCP setup guide, and the method reference is in the MCP docs.
The cost is mobility. A stdio server only works on the machine it runs on, so an agent you want to reach from your phone needs a remote option. That is the trade, and it is a clean one.
What managed actually buys you
Managed gets a bad write-up in privacy discussions, which is unfair. It buys real things.
Someone else handles OAuth app registration, which is tedious and easy to get wrong. Someone else patches the server when a dependency has a problem. It works from any device without you opening a port or running a tunnel. And it keeps working when your laptop is shut.
For a scheduled agent that runs at seven each morning whether or not you are awake, managed or self-hosted remote are the only options. A stdio server cannot run when no client is running.
The question to ask a managed provider is narrow: what do you store, where, and for how long. Specifically, do they hold a long-lived refresh token for your accounts, and are request and response bodies written to logs. A provider that keeps tokens but logs nothing is a different risk from one that keeps both.
A dedicated cloud account or a single-tenant deployment does not answer this on its own. Ask whether tenants share encryption keys, storage or workers. The reasoning carries over from the enterprise case in what we learned testing 10 self-hosted AI agents against our guardrails.
The hidden cost of self-hosted remote
Self-hosting looks like the privacy answer and often is. But you have taken on a job, and it is worth naming the job before you accept it.
You now run a service on the internet that holds tokens for your email and your files. You patch it. You renew its TLS certificate. You decide whether it is reachable publicly or only over a VPN. If you forget about it for eight months, it is still there, still holding your tokens, running an old version.
A forgotten self-hosted server is worse than a managed one, because at least the vendor has someone whose job is to patch it. Be honest about whether you will keep up with it.
If you do go this route, put it behind Tailscale or a similar private network rather than exposing it publicly. You keep the remote access and lose the public listener, which is most of the benefit of stdio with none of the mobility cost.
Where credentials sit matters more than where the server runs
Here is the part that cuts across all three models.
An MCP server can hold your tokens itself, or it can ask something else for them at the moment a call runs. The second arrangement is better in every model, including managed.
In that arrangement the credential never passes through the model's context, so a leaked conversation contains no working key. It also means the token store is one thing you can protect properly rather than a copy in every integration. That is the argument in keep API keys out of the LLM and the requirements are set out in what a credential vault needs to do for AI agents.
So when you compare options, ask where tokens are stored and whether they are encrypted at rest, before you ask who operates the box.
How to choose
Work through these in order and you will land on one.
- Does the agent need to run when you are not at your machine? If no, use local stdio and stop here. This covers most personal setups.
- If yes, will you patch a server and keep track of it? If no, use managed and pick the provider by what it stores.
- If yes, self-host, and put it on a private network rather than the public internet.
- Whichever you choose, check that tokens are encrypted at rest and never reach the model's context.
- Whichever you choose, keep the allowlist narrow. The server model does not change what the agent should be allowed to do.
That last point gets forgotten. Running a server yourself does not make a send-email method safe. The limits in what a personal AI agent should never be allowed to do apply the same way in all three models.
Setting up the local option
npx swytchcode
swy login
swy init
swy get gmail
swy auth connect gmail # token stored locally, encrypted at rest
swy auth status
swy discover "list messages" --project gmail
swy add method <canonical_id>
# Then point your client at the stdio server and restart it.Credentials go to a local store outside your project and are attached when a call runs. Nothing listens on a port. Details are in the authentication docs.
FAQs
Is a local MCP server more secure than a managed one?
It removes two things: a network listener and a third party holding your tokens. That is a genuine reduction. It does not protect you from an over-permissioned allowlist, from prompt injection, or from your own machine being compromised.
Can I run a local server and still use it from my phone?
Not with stdio, which needs a client on the same machine. A private network such as Tailscale plus a self-hosted remote server is the usual way to get phone access without a public endpoint.
What should I ask a managed MCP provider?
Do you store refresh tokens, and where. Are request and response bodies logged, and for how long. Do tenants share encryption keys or storage. Can I revoke everything from one place. Short, specific questions get useful answers.
Does the model still see my data in the local setup?
Yes, if you use a hosted model. Running tools locally keeps credentials and execution on your machine, but whatever the agent puts in the prompt goes to the model provider. Running a personal agent on your own machine draws that line properly.
Which MCP servers are worth starting with?
Start with the one or two apps you use most, rather than connecting everything. Best MCP servers for ChatGPT in 2026 covers the common ones, and bring your own MCP covers the case where no server exists for the API you need.
Related reading
More content
Running a personal agent on your own machine
Local execution and local inference are different things, and conflating them is how people end up believing their data never leaves. Here is the honest boundary.
Chaitrali KakdeA personal finance agent that cannot move money
Open banking separates reading your accounts from moving your money into two different consents. Grant one and not the other, and payment is not something your agent can be talked into.
Chaitrali KakdeGiving a personal agent access to your email without regret
An agent that can read your email is one product. An agent that can send is a different product with different risks. The OAuth scope you pick decides which one you built.
Chaitrali Kakde