Choose remote when the tool holds shared data and you want central sign in, tokens and revocation. Choose local only when the data is on the machine anyway and you can vet and sandbox the code. A local server runs with the same privileges as the client, which is the main risk to weigh.
The core difference
The MCP architecture overview explains the split. A local server uses the stdio transport and usually serves one client on the same machine. A remote server uses Streamable HTTP and usually serves many clients, with OAuth recommended for tokens.
Claude's documentation adds a practical point: desktop extensions are local MCP servers packaged for single click install, and advanced research cannot use local servers.
Comparison
| Factor | Local server | Remote server |
|---|---|---|
| Where code runs | Your workstation | Vendor or your cloud |
| Credentials | Environment variables | OAuth or fixed header |
| Updates | You or the extension store | The server operator |
| Blast radius | Your user's file and network access | The scopes of the token |
| Network need | None | Public endpoint or allowlist |
| Fit for shared findings | Weak | Strong |
What the security guidance says about local servers
The MCP security best practices page lists local server compromise as a distinct risk. Attackers may embed a malicious startup command in a configuration, ship a payload inside the server, or reach an insecure server left running on localhost. The page notes that local servers run with the same privileges as the client and recommends consent dialogs that show the exact command, plus sandboxing with minimal default privileges.
It also says servers meant to run locally should use stdio to limit access to the client, or require an authorization token over HTTP.
A decision path
- Does the security data live in a shared platform? Prefer remote.
- Is the tool a small helper that reads local files, such as a lockfile? Local may be fine.
- Can you read the code and pin the version? If not, do not run it locally.
- Can the endpoint be public with proper authentication, or allowlisted? If not, local may be the fallback.
- Who updates it? Name an owner either way.
Mistakes to avoid
- Installing a local server from a one click link without reading the command.
- Putting long lived keys in a shared configuration file under version control.
- Assuming that local means safe. Local means your machine is the target.
A worked example: three tools, three answers
These are hypothetical tools used to show the reasoning.
Tool 1, a dependency checker that reads a lockfile in the current folder. It needs local files and returns advisories from a service. A local server fits, since the input is on the machine. The team pins a version, reads the startup command, and runs it with access only to the project folder.
Tool 2, a vulnerability platform holding findings for fifty projects. The data is shared and sensitive and belongs behind central sign in. A remote server fits. The team requires OAuth, scopes and logging, and confirms the endpoint rules.
Tool 3, a helper from a public repository that promises to do both. Nobody on the team can say who maintains it. The team declines until an owner can be named. This is the case the best practices page worries about, where a startup command is run on trust.
Step by step: vet a local server before first run
- Find the exact startup command in the configuration or installer. The guidance says clients should show the exact command without truncation.
- Read it. Look for network calls, shell chains and access to home directory paths.
- Identify the package source and the maintainer. Pin a specific version, not a floating one.
- Run it in a sandbox, such as a container or a separate account with minimal rights, as the guidance recommends.
- Give it only the folders it needs.
- Store its credential in an environment variable that is not committed to version control.
- Watch the first run, then decide whether to keep it.
Step by step: vet a remote server
- Confirm the operator and hosting details.
- Test the endpoint for refusal without a valid token.
- Review scopes and tools.
- Review logging and change notices.
- Decide who owns the connector and when it will be reviewed again.
Cost of each choice
| Cost | Local | Remote |
|---|---|---|
| Review effort | Read code and commands on each machine | Review once, centrally |
| Update effort | Each machine or extension store | Vendor handles it, you track changes |
| Incident scope | One workstation, with its credentials | Whatever the token allows |
| Offboarding | Uninstall and remove credentials | Revoke the user at the vendor |
Mixed estates
Most teams end up with both. The risk in a mixed estate is losing track. Keep one register that lists every connector with a column for local or remote, and review local ones more often, because they run code on devices that also hold email, source code and keys.
What to avoid
Do not install a local server because a web page offers a one click button. The guidance says one click configuration needs a consent step that shows the command and warns that it runs code with the client's privileges. If your client does not show that, pause.
Where Safeguard fits
Safeguard offers asset discovery for inventory and an MCP Guardrail for policy on what agents may call. Neither replaces reading a server before you run it. The Safeguard CLI, installed with a curl or PowerShell installer, can also write code, and the download page lists a Local agent and a Cloud agent as available.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare how the server is configured and what it can reach before you decide where it should run.
Quick check
Is a local server safer because it is not on the internet?
Not automatically. It runs with your privileges, so a malicious or buggy server can reach files and credentials on your machine.
Can research mode use local servers?
Per Claude's help center, advanced research cannot use local MCP servers.
Can I run both a local and a remote server for the same tool?
Yes, but treat them as two connectors with two reviews and two sets of credentials.
Sources
- MCP architecture overview
- MCP security best practices
- Claude Help Center, custom connectors using remote MCP
- Claude Help Center, local MCP servers on Claude Desktop
Last reviewed: 19 October 2026.
