Local vs. remote MCP servers: how to choose

Choose a local MCP server when one person or one workstation needs access to local resources and can manage the runtime. Choose a remote server when several users, devices, or hosted agents need a centrally operated integration.

That is the short answer. The important caveat is that “local” and “remote” describe where the MCP server runs and how the client reaches it. They do not, by themselves, tell you where tool inputs, provider requests, tool results, or model context travel.

Examples on each side of that line: Google Home MCP is a remote, OAuth-backed endpoint for physical devices; LUCI is loopback-only local memory for coding agents; a team may route IDE clients through an MCP gateway proxy before calls reach either shape. Cursor Self-Hosted Machines adds a hybrid where local workers execute tools while planning stays in Cursor's cloud. OpenAI Agents API can reach MCP from OpenAI (service origin) or from your session environment, including stdio inside the sandbox.

The current MCP protocol version is 2026-07-28. Its transport specification defines two standard transports, and the protocol means the same thing on both.

Stdio has the client launch the MCP server as a subprocess. Messages are newline-delimited JSON-RPC over the process's standard input and output, and the server may write logs to stderr but nothing except MCP messages to stdout. This is the common local shape. There is no listening TCP port, and the process usually receives configuration or credentials through its environment.

Streamable HTTP has the client send every JSON-RPC message as its own HTTP POST to a single MCP endpoint. The server answers each request with either one JSON object or a Server-Sent Events stream scoped to that request. This supports remote deployments, shared services, and independent server lifecycles. It can also run on localhost, so HTTP does not necessarily mean remote. The Streamable HTTP binding says servers must validate the Origin header to block DNS rebinding attacks, and a local server should bind only to 127.0.0.1, not to every network interface.

The old HTTP-plus-SSE transport from the 2024-11-05 protocol version has been deprecated since 2025-03-26 and is eligible for removal in a future revision. Compatibility with older clients may still require it, but new deployment decisions should start with Streamable HTTP and the client versions you actually support.

The 2026-07-28 changelog makes MCP stateless, and that changes the remote side most:

• There is no initialize handshake. Every request carries its protocol version and client capabilities in its own metadata, and servers must answer a new server/discover call that lists their supported versions and capabilities.
• Streamable HTTP no longer has protocol-level sessions or the Mcp-Session-Id header, and the separate GET stream is gone. Change notifications, such as a changed tool list, arrive on the response stream of a subscriptions/listen request the client opts into.
• A server that needs state across calls passes an explicit handle as an ordinary tool argument.
• Interrupted streams are no longer resumed. If a response stream breaks, the client must send the request again with a new request ID, so write tools need to be safe to retry. Our post on webhook idempotency for AI agents covers the same retry problem.
• Server-to-client requests such as sampling and elicitation now come back inside a result that asks the client for more input, and the client retries the original request with the answers.

Clients and servers on older revisions are still supported through a fallback described in the spec, so a mixed fleet keeps working while you upgrade. For a remote deployment, check which revision each client and server you depend on actually speaks before you rely on the new behavior.

A typical local setup looks like this: an AI host starts a server command on the user's machine; the server reads files or calls an API; the result returns to the host; the host may include some or all of that result in a model request.

Running the MCP process locally can keep the MCP transport off the network. It does not guarantee that the workflow stays on the device. A local Google Ads server still calls Google. A local search server still calls search providers. A local code-retrieval server may use a hosted embedding or language model unless configured for local providers. The AI host's model may also be remote.

Do not turn deployment location into a privacy guarantee. The answer comes from the full data flow and the policies of every service in it.

Local stdio is often the best starting point for developer tools, personal knowledge access, and filesystem-bound workflows. It has fewer network components, can use the user's existing local credentials, and can access resources that are not exposed outside the machine.

It also creates a straightforward distribution model for some tools: install a package, add a client configuration, and let the host manage the process lifetime. Several of our public MCP projects, including the code-search and provider-tool servers, use this shape.

The tradeoff is fleet management. Every workstation needs a compatible runtime, package version, credentials, configuration, and operating-system permissions. Updating ten installations is different from updating one service. Debugging also depends on the host's process environment, current working directory, and log capture.

Local servers run with the permissions of the launching client unless stronger isolation is applied. The official MCP security guidance warns that a malicious or compromised local server can execute code or access data with those privileges. Stdio removes a listening port; it does not make an untrusted package safe.

A remote MCP server is usually the better shape for shared business integrations, hosted agent systems, and data that already lives behind a central API. The team operates one deployment, applies one release, centralizes monitoring, and can enforce identity and tenant policy at a common boundary.

Remote deployment also supports clients that cannot launch local subprocesses. A web-based host or hosted automation service can connect to an HTTPS endpoint without asking every user to install Node.js, Python, or a provider SDK.

The cost is a much larger operational surface. You now own TLS, authentication, authorization, origin checks, rate limits, any cross-call state, availability, scaling, secrets, tenant isolation, and incident response. Centralization reduces endpoint drift but increases the impact of a server-side mistake.

For HTTP deployments, MCP has an authorization framework built on OAuth 2.1. The specification says HTTP implementations should conform to it, while stdio implementations should retrieve credentials from the environment rather than use that HTTP flow. In the 2026-07-28 revision, Client ID Metadata Documents are the preferred way for clients to register, Dynamic Client Registration is kept only for backward compatibility, and clients must check the issuer returned with an authorization response. Authentication still does not replace per-tool and per-object authorization.

Users and devices. One technical user on one machine favors local. A team, multiple devices, or hosted agents favors remote.

Data location. Files available only on a workstation favor local. A SaaS API or central database often favors remote, unless policy requires calls to originate from a managed endpoint.

Identity model. A local server can act under the current operating-system user and locally supplied credentials. A remote server needs a verified caller identity, tenant mapping, and a clear model for delegated versus service credentials.

Updates. Local distribution requires version management across clients. Remote deployment lets the operator update one service, but every change can affect all users at once and needs compatibility discipline.

Availability. A local server is available when the machine and host are running. A remote service can be always on, but it needs health checks, redundancy, timeouts, and an outage plan.

Latency. Stdio avoids an MCP network hop, which helps small frequent calls. In many integrations, the downstream provider call dominates latency anyway. Measure the whole path instead of assuming transport is the bottleneck.

Cost. Local compute is distributed to user machines, while remote compute, bandwidth, observability, and on-call work become an operator expense. Provider API costs exist in either model.

Control and audit. Remote services make centralized policy and logs easier. Local servers may keep sensitive raw data nearer the user, but consistent audit collection and revocation are harder across a fleet.

Blast radius. A compromised local server may expose one machine and that user's authority. A compromised remote multi-tenant server may expose a larger shared surface. This is a tendency, not a guarantee; actual permissions and isolation decide the impact.

Some workflows need both shapes. A small local server can read files or interact with desktop-only software, while a remote service handles shared policy, indexing, or access to a central business API. Another option is a remote server with a local connector that initiates an outbound connection from a private network.

Hybrid architecture is useful when the boundary is real, not as a default. It adds another identity relationship, deployment, failure mode, and data path. Write down exactly which component can see raw data and which one can perform writes.

Avoid using a local proxy merely to make a remote service appear private. If the proxy forwards the same data to the same external endpoint, the privacy properties have not changed.

Not every MCP host supports every transport, authorization feature, protocol revision, or user-interaction flow. Before designing the infrastructure, test the target hosts.

At minimum, verify version negotiation (server/discover on 2026-07-28, and the fallback for older clients), tool discovery, structured results, error display, cancellation or timeout behavior, and what happens when a request is retried after a dropped stream. For remote servers, verify the complete authorization flow, and any state you carry across calls in explicit handles. For local servers, verify command configuration, environment handling, executable paths, shutdown, and that logs do not corrupt stdout.

The MCP architecture guide explains the host-client-server relationship: a host creates a client for each server connection. That separation helps explain why one AI application may connect to several local and remote servers at once.

A developer wants semantic search across a private checkout on a laptop. Start local. Index locally, restrict the allowed project root, and decide separately whether embeddings or model calls use a local or hosted provider.

A sales team wants several people to query and update one CRM. Start remote. Use individual identity, object-level authorization, narrow read and write scopes, central audit logs, rate limits, and explicit approval for consequential actions.

A clinic needs access to a system available only inside a managed network. The answer depends on the system architecture and policy: a managed server inside that network, a restricted connector, or a local deployment on approved workstations may fit. “MCP is local” is not a compliance analysis.

A hosted agent needs a search tool. Remote is usually more practical because the agent cannot launch a process on each end user's laptop. Constrain destinations, results, provider credentials, and spend at the service boundary.

Start with local stdio when the scope is one trusted user, the data is local, and workstation management is acceptable. Start with remote Streamable HTTP when access is shared, the server must remain available independently, or the client cannot run subprocesses.

Then test the choice against the data flow, identity model, client support, revocation plan, and worst plausible failure. If the design cannot explain who can invoke a write and where its data travels, transport selection is premature.

For the controls required after choosing a deployment, read how to secure an MCP server for production. For a vendor-hosted remote server in practice, see our post on the Webflow MCP server. If you need a scoped implementation for an existing business system, see custom MCP server development, or start with the free automation audit.

Update, October 2026: the MCP tutorials page now has a learning path that ends with hosting a server behind sign-in. For when MCP is the right layer at all, see MCP servers vs API integrations.