Guide
Remote vs local MCP servers: which does your team need?
Both expose the same kind of tools to Claude. The difference is where the server lives, who can reach it, and what happens when a laptop goes to sleep.
Remote vs local MCP servers comes down to where the server runs. A local MCP server runs on one person's machine, good for personal and developer use but tied to that computer. A remote MCP server is hosted, reachable over HTTPS with OAuth, works in claude.ai, and serves a whole team from one centrally maintained place.
Key takeaways
- A local MCP server runs on one machine and serves one person; it stops when that machine does.
- A remote MCP server is hosted, reachable over HTTPS with OAuth, and works in claude.ai for whole teams.
- Remote servers are maintained and updated centrally, so a fix ships once instead of laptop by laptop.
- Done-for-you connectors are hosted remote MCP servers, so teams get the remote model without running anything.
What is the difference between a remote and a local MCP server?
Both are MCP servers: programs that expose tools like `search_records` and `update_record` for Claude to call. A local server is a process running on your own computer, connected to a desktop client on that machine. A remote server runs on hosted infrastructure and is reached over HTTPS, with OAuth handling who gets in.
The tools themselves can be identical. What changes is the plumbing between Claude and the server, and everything that plumbing implies about sharing, uptime, and maintenance.
If you want the layer-by-layer picture of how MCP relates to the APIs underneath, our MCP vs API explainer covers that. This post assumes the connector exists and asks a narrower question: where should it live?
When is a local MCP server the right choice?
A local server is the right choice for personal and developer use. It is quick to spin up, it can reach things that only exist on your machine like local files and development databases, and nothing sensitive leaves your computer. For one technical person experimenting or building, local is genuinely the better fit.
Local shines when:
- You are a developer testing tools against a local project or database.
- The data the server needs lives on your machine and should stay there.
- You are the only user and do not need the connector from a browser or phone.
The limits are just as concrete. The server dies when the laptop sleeps or restarts. It is hard to share: a colleague who wants the same tools has to install and configure their own copy. And every copy has to be updated by hand, on every machine, forever.
When does a team need a remote MCP server?
A team needs a remote server as soon as more than one person should use the same connector, or anyone needs it in claude.ai rather than a desktop app. Remote servers are always on, shared through a URL instead of an install, and secured with OAuth so each person connects under their own identity.
The remote model changes the day-to-day experience:
- It works in claude.ai, so browser and mobile sessions get the same tools as desktop.
- Everyone connects to one server; nobody installs or configures anything locally.
- OAuth ties access to each user's own login, so permissions follow the person.
- Updates and fixes deploy once, centrally, instead of machine by machine.
For a team that wants shared, always-on connectors to its business software, remote is the answer. There is no version of the local model that scales past a couple of technical users without turning into an IT chore.
Does remote mean less secure?
No, remote done well is usually more controlled, not less. Access runs over HTTPS with OAuth, so every user authenticates individually and the server acts within that user's permissions. Compare that with local setups, where credentials often sit in plain config files on each laptop that runs a copy.
Centralizing the server also centralizes the guardrails. Scoping, confirmation gates on destructive actions, and credential handling are implemented once and apply to everyone, instead of depending on how carefully each person set up their own instance.
The trade-off is operational, not just technical
A remote server is something that must be hosted, monitored, and updated. That is real work, which is why teams either assign it to engineering or use a service that runs the server for them.
Who runs the remote server?
Someone has to host it, keep it patched, renew its credentials, and update it when the underlying software or the MCP spec changes. Your engineering team can own that, or you can use done-for-you connectors, which are hosted remote MCP servers: built, run, and maintained as a service.
If your company already operates production services, adding an MCP server to that portfolio is a known kind of work.
If it does not, or engineering time is better spent elsewhere, the done-for-you model gets you the remote architecture without the operations: a hosted server with OAuth, scoped read-write tools in your real schema, and confirmation gates on risky actions, ready to add to your team's Claude workspace. The how-it-works page walks through exactly what that setup looks like.