Remote MCP Servers: When to Choose Hosted Over Local

A remote MCP server runs on someone else’s infrastructure and your assistant reaches it over HTTPS, usually after an OAuth sign-in. A local server runs as a process on your own machine. Remote servers are easier to share across a team and to revoke, while local servers keep data on your computer.

Local and remote side by side

The choice is mostly about who runs the code and where credentials live.

Question	Local (stdio)	Remote (HTTP)
Where does it run?	A subprocess on your machine	A hosted service
Network exposure	None	Over the internet, with auth
Typical credentials	Your local keys or env vars	OAuth grant or bearer key
Sharing with a team	Each person installs	One endpoint, many users
Updates	You update the package	Publisher updates it
Works offline	Often yes	No

BusinessMCP’s explainer on what MCP is describes the local transport as having no network exposure and using the user’s local credentials, and the remote transport as Streamable HTTP over HTTPS. That is consistent with the official specification.

Key takeaway: remote does not mean riskier, and local does not mean safer. A local server with a full-access token and unreviewed code can do more damage than a remote one with a narrow OAuth scope.

Why teams move to remote servers

Several practical reasons recur.

• One setup, many people. Instead of each developer installing a runtime and pasting a key, the team connects to a shared endpoint.
• Central revocation. When someone leaves, you revoke their grant at the provider rather than hunting for keys in config files.
• No local dependencies. No Node or Python version conflicts.
• Vendor-maintained. Official remote servers stay in step with the vendor’s API.

BusinessMCP, for example, offers a hosted endpoint that you reach with a bearer key and says keys are scoped per connection and can be revoked. Its Claude Code page shows the one-line setup. These are the vendor’s own descriptions, so test them against your requirements.

How authentication works

For HTTP servers, the specification describes OAuth: the server acts as a resource server and publishes metadata so a client can discover how to get a token. BusinessMCP’s summary adds that a later specification revision introduced resource indicators so a token issued for one server cannot be reused on another. In practice you see one of three patterns:

1. OAuth sign-in. You click connect, log in, approve scopes. Best for revocation.
2. Bearer API key. You paste a key into a header. Simple, but the key is long-lived, so scope it tightly.
3. Mixed. The same server accepts either.

Whichever you use, never expose an unauthenticated MCP server to the internet. BusinessMCP’s guidance calls it an API into your business, and recommends authenticating every request, scoping access per key, rate limiting, keeping an audit log and requiring approval for high-impact actions such as sending email.

What to check before connecting a remote server

1. Publisher identity. Is it the vendor itself, or a third party wrapping the vendor’s API?
2. Data path. Your requests and the results travel through their servers. Read their privacy and security pages.
3. Scopes. Can you grant read-only access?
4. Audit and revocation. Can you see what was called and cut access instantly?
5. Tool list. Which tools can write, send or delete?
6. Status label. On a directory such as the BusinessMCP MCP server directory, see whether it is Official, Verified or Archived, and what those mean in official vs verified MCP servers.

When local still wins

Choose local when the server touches local files, when you work offline, when the data must never leave your machine, or when you are developing the server itself. A filesystem server restricted to one folder, or a SQLite file on your laptop, rarely makes sense as a remote service.

Connecting from common clients

Remote support is broad but the screens differ. For a terminal agent the add command takes a transport type and URL, covered in Claude Code MCP servers. In the desktop app, hosted servers are typically added as connectors; see Claude MCP servers. Each client’s documentation has the current steps.

A short decision guide

• Solo, personal files or offline: local.
• Team, SaaS data, easy offboarding: remote.
• Sensitive data with strict residency rules: ask the publisher where it is processed, or run the server yourself.
• Not sure: begin with a read-only remote server from an official publisher, then reassess.

Whichever you pick, the basics from are MCP servers safe still apply: least privilege, a small tool set and a habit of reading what the agent is about to do.

Running your own remote server

Some teams host their own. That gives control over logging and data residency, at the cost of operating it. If you go this route, treat the endpoint as an internet-facing API: require authentication on every request, scope keys, rate limit, log calls and keep dependencies patched. BusinessMCP’s documentation includes a guide to exposing your own MCP endpoint, and a hosted option for teams who prefer not to run infrastructure; read the directory for examples of what hosted servers look like.

Latency and reliability

A remote server adds a network hop to every tool call. Usually this is a fraction of a second, but outages and rate limits become your problem in a new way: if the provider is down, the assistant loses that tool. Keep a fallback for critical workflows, such as the ability to run the underlying query by hand, and watch the provider’s status page. Local servers avoid this dependency but add their own: your laptop must be on and the runtime installed.

Offboarding and revocation in practice

Plan for people leaving. With OAuth, you revoke their grant at the provider. With shared bearer keys, you must rotate the key and update everyone else, which is why per-person keys are better than one team key. Write down where each key was issued, so revocation is a two-minute job rather than an investigation.