Remote vs Local MCP Servers: Authentication, Deployment, and Which to Choose

The difference between a local and a remote MCP server sounds like a deployment detail and turns out to determine almost everything else: how the server authenticates, who can use it, which clients can reach it at all, and who carries the operational burden. A local server is a subprocess that your MCP client launches on your machine and talks to over standard input and output. A remote server is an HTTP service that any client can reach with a URL. That single architectural choice cascades into the authentication model, the number of users a server can serve, whether browser-based agents can connect, and whether adding the server to a team is a per-laptop installation or a single link.

• Browser-based agents cannot spawn local subprocesses. This is the constraint that settles the decision for many teams before any other factor is considered. If ChatGPT on the web or Claude.ai needs to reach your tools, remote is the only option.

• The transports are stdio for local and Streamable HTTP for remote. The older HTTP+SSE transport from the 2024-11-05 revision is formally deprecated with a year-long offramp. Streamable HTTP is now the single remote transport.

• GMI Cloud’s MCP server is remote by design. It lives at a URL, authenticates through a one-time browser sign-in, and requires no API key pasted into a configuration file, which is the property that distinguishes it operationally from a local server.

• Authentication is the sharpest difference. A stdio server inherits your local permissions and needs no client-to-server authentication at all. A remote server must implement it: OAuth 2.1 with RFC 9728 Protected Resource Metadata is the specified path.

• The 2026-07-28 specification made remote servers stateless. No initialize handshake, no session header, which means any replica of a remote server can serve any request. This was a breaking change and it is what makes horizontal scaling of remote MCP servers straightforward.

• stdio is not deprecated and remains correct for local access. A server that reads your file system, queries a local database, or drives a CLI belongs on stdio. The question is not which transport is better but which problem you are solving.

The Two Architectures

A local server is a subprocess. The MCP client launches it as a child process when the client starts, and the two communicate over standard input and output. The server runs on the same machine as the client, with the same file system access and the same user permissions. Configuration is a shell command in the client’s config file, typically with environment variables supplying any credentials the server needs.

A remote server is an HTTP service. It runs independently of any client, exposes a single MCP endpoint such as https://example.com/mcp, and clients reach it over the network with plain HTTP requests. Configuration is a URL. The server has whatever access its own deployment environment provides, which is unrelated to the user’s machine.

Authentication: The Sharpest Difference

Local servers do not authenticate to the client. The client starts the server as its own subprocess, so there is no network boundary to defend and no identity to establish. The server runs as you, with your permissions.

Credentials that the server needs for its own downstream work, such as an API key for a third-party service, come from environment variables. The specification is explicit that stdio servers should retrieve credentials from the environment rather than follow the HTTP authorization framework.

This is convenient and it is also the source of the most common local-server security complaint: those credentials end up in a configuration file on disk, in plaintext, on every machine that runs the server.

Remote servers must implement authentication, and the specification defines how. The transport introduced in the 2025-06-18 specification uses OAuth 2.1 together with other standards-based mechanisms to authenticate and authorise MCP clients.

The mechanism a client uses to discover that authentication is required matters more than it appears. An unauthenticated request should receive a standard 401 response carrying a resource_metadata link, following RFC 9728 Protected Resource Metadata. A server that instead returns a 403 or a redirect breaks the discovery step, and the OAuth flow never starts. This is a frequent implementation error and it presents to the user as a connection that simply fails.

Three OAuth modes cover the practical cases.

Machine-to-machine using client credentials, appropriate when the caller is a service rather than a person.

Non-DCR, where clients are manually pre-registered with the identity provider, appropriate when the set of clients is known and controlled.

Dynamic Client Registration, where clients register themselves at connection time, which is what allows an arbitrary MCP client to connect without the server operator provisioning it in advance.

What this means in practice for a user. Connecting to a well-implemented remote server is a browser consent screen followed by a redirect back to the client. No key is copied, no configuration file is edited, and revoking access later is a token revocation rather than a search through config files on several machines.

What the 2026-07-28 Specification Changed

The specification revision current as of late 2026 made three changes that affect this decision directly.

Streamable HTTP is the single remote transport. The older HTTP+SSE transport from the 2024-11-05 revision, which used a separate SSE endpoint alongside a POST endpoint, is formally deprecated with a year-long transition period. New remote servers should implement Streamable HTTP only.

The protocol is stateless. There is no initialize handshake and no session header. This removes the constraint that a client’s requests must all reach the same server instance, which means any replica of a remote server can serve any request. For anyone operating a remote server at scale, this is the change that makes horizontal scaling straightforward: put the service behind a load balancer and add replicas.

It was a breaking change. Code written against the 2025-11-25 revision that depends on Mcp-Session-Id or on an initialize call will not interoperate with a 2026-07-28 client. Teams running remote servers built before this revision need to verify compatibility rather than assume it.

The revision also deprecates three older client features: roots, sampling, and logging. Servers that relied on them need a different approach.

The Constraint That Usually Decides It

For a large share of teams, the decision is made by a single factor that has nothing to do with preference.

Browser-based clients cannot launch local processes. ChatGPT on the web, Claude.ai in a browser, and any hosted agent platform run in an environment that has no ability to spawn a subprocess on the user’s machine. If those clients need to reach your tools, a remote server is the only mechanism.

This cuts the other way too. A server whose entire purpose is reading local files or driving a local CLI cannot usefully be remote, because a remote deployment has no access to the user’s machine. The tools it would expose would operate on the server’s environment instead, which is a different product.

The second deciding factor is team distribution. A local server must be installed and configured on every machine that uses it. Every user needs the runtime installed, the correct version, and the credentials in their config file. Every update is a coordinated rollout across laptops.

A remote server is deployed once. Adding a user is sharing a URL. Updating the tool set is a deployment, and every connected client sees the change on its next request.

For a team of two engineers, the installation burden is trivial. For an organisation of two hundred, it is the difference between a tool that gets adopted and one that stays in a README.

The Credential Problem With Local Servers

The security argument against local servers is specific and worth stating plainly, because it is the reason many hosted services now offer remote servers exclusively.

A local MCP server that needs to call an external API needs that API’s credentials. The specification directs stdio servers to read them from the environment, which in practice means they are written into the client’s configuration file.

That file sits in plaintext on the user’s machine. It is frequently committed to a dotfiles repository by accident. It is readable by any process running as that user. Rotating the key means updating every machine. Revoking a single user’s access means finding and editing their specific configuration.

The credential in that file is typically a long-lived API key with the full permissions of the account it belongs to, because MCP servers rarely offer scoped keys. An agent that has been manipulated into misusing a tool has the full authority of that key.

A remote server with OAuth changes this materially. The user authenticates in a browser to an identity provider, the client receives a scoped token with a limited lifetime, and no long-lived secret is stored on disk. Revocation is server-side and immediate. The scope of what the token permits is defined by the server operator rather than by whatever the API key happens to allow.

This is the operational reasoning behind GMI Cloud’s MCP server using a one-time browser sign-in rather than an API key in a config file, and behind the tool surface being deliberately non-destructive: no deletes, no account changes, no operations that cannot be undone.

Operational Differences Once the Server Is Running

The choice also determines who carries which operational responsibilities.

Version management. Local servers are versioned per installation. A user running an old version encounters bugs that were fixed months ago, and there is no central way to know which versions are in use. Remote servers have exactly one version in production at any time.

Observability. A local server produces logs on the user’s machine, which nobody reads. A remote server logs centrally, which means tool call volume, error rates, latency, and usage patterns are visible to the operator. For anyone trying to understand how their tools are actually used, this difference is substantial.

Rate limiting and quotas. A local server cannot meaningfully enforce a quota, because each installation is independent. A remote server enforces limits centrally, per user or per organisation.

Incident response. A bug in a local server requires every user to update. A bug in a remote server is fixed with a deployment.

The cost. All of the above is work the operator now owns. A remote server needs hosting, uptime monitoring, an on-call rotation, an OAuth implementation, and protocol revision upgrades. The 2026-07-28 revision being a breaking change is a concrete example: every remote server operator had to handle it, while local server users upgraded whenever they happened to reinstall.

The Proxy Pattern

There is a middle path worth knowing about for teams with an existing stdio server.

A proxy speaks Streamable HTTP to clients on one side and stdio to the existing server on the other. The stdio server is unchanged; the proxy handles the transport translation, the OAuth flow, and the network exposure.

This is useful when the existing server represents significant work that should not be rewritten, or when the same server needs to serve both local users on stdio and remote clients over HTTP during a transition.

The limitation is that the proxy inherits the stdio server’s assumption of a single user. A stdio server that maintains state in memory or writes to a fixed path on disk does not become multi-tenant by being placed behind a proxy. If the server needs to serve many users concurrently, it needs to be built for that regardless of how the transport is handled.

Building for Remote: What Changes in the Server

For teams writing a server rather than consuming one, the migration from local to remote is less work than it appears at the transport layer and more work than it appears everywhere else.

The transport swap is small. A server built with the MCP SDK exchanges its stdio transport for the Streamable HTTP transport. The tool definitions, the handlers, and the business logic are unchanged. Everything a client saw before, it sees after.

The authentication layer is new work. The server becomes an OAuth resource server. It serves protected resource metadata at a well-known path, validates tokens on every request, and returns a correctly formed 401 with a resource metadata link when a request arrives unauthenticated.

Multi-tenancy is the part that is easy to underestimate. A local server serves one user and can hold state accordingly. A remote server serves many concurrently and must scope every operation to the authenticated identity. Any state the server holds must be keyed by user. Any file it writes must not collide across users. Any quota it enforces must be per-tenant.

Statelessness helps here. Because the 2026-07-28 protocol carries no session state, the server does not need to maintain per-connection state across requests. Each request arrives with its own authentication and is self-contained, which aligns well with a horizontally scaled stateless service.

Testing both entry points. Teams maintaining both a stdio and a remote entry point should assert that the two expose an identical tool list, which is a cheap test that catches the common failure of a tool added to one entry point and not the other.

The Decision

Choose a local stdio server when the tools need access to the user’s machine, the server is for development or personal use, the user base is small enough that per-machine installation is not a burden, and no browser-based client needs to connect.

Choose a remote Streamable HTTP server when browser-based clients need access, the server serves a team or an organisation rather than an individual, the tools operate on a service rather than on local files, credentials should not live in configuration files on user machines, or you need central observability, quotas, and version control.

The question underneath both. What does the tool need access to? A tool that reads your local repository must run where your repository is. A tool that generates a video on GPU infrastructure must run where that infrastructure is. The transport follows from that, and most of the other considerations follow from the transport.

What This Looks Like With GMI Cloud

GMI Cloud’s MCP server is remote because the tools it exposes operate on cloud infrastructure rather than on the user’s machine. Model discovery, cost estimation, and media generation all run on GMI infrastructure, so there is nothing a local subprocess would add.

The practical consequences follow the pattern above. Connection is a URL plus a browser consent flow rather than an installation. Any MCP client works, including browser-based ones. There is no API key in a configuration file. The tool surface is deliberately read-and-create only, with no destructive operations exposed to an agent. Every call lands in console history and billing, which is the central observability that a local server cannot provide.

The launch post, GMI MCP Server: Turn your assistant into a production studio, covers the tool surface and the setup path for each client.

For teams building agents that consume MCP servers rather than assistants that call them, GMI Agentbox provides the deployment and runtime layer, and the governance considerations for agent tool access are covered in Agentic Infrastructure Governance.

Conclusion

Local and remote MCP servers are not competing implementations of the same thing. They solve different problems, and the transport choice is downstream of what the tools need access to.

A local stdio server runs on the user’s machine, inherits their permissions, needs no authentication, and cannot be reached by browser-based clients. It is the correct choice for tools that operate on local files and processes, and it remains fully supported.

A remote Streamable HTTP server runs independently, authenticates with OAuth, serves many users concurrently, and is the only path to browser-based clients. It costs the operator a deployment, an authentication implementation, and ongoing protocol maintenance, and it gives every user a URL instead of an installation.

The 2026-07-28 revision made this cleaner by consolidating on a single remote transport and removing session state, which means a remote server is now a stateless HTTP service that scales like any other. For a hosted service exposing its capabilities to agents, that is the shape the protocol now expects.