Where should an MCP server run? Trust, auth, data and upkeep

An MCP server can live in two very different places. It can be a small program your agent client starts on your own machine, or a service somewhere on the network that the client reaches over HTTP. The protocol messages are the same either way, so the choice can look like a deployment detail. It is not. Where the server runs decides whose code you are trusting, how credentials are stored, which data crosses your boundary and who has to keep the thing working. This page walks through those trade-offs and ends with a checklist you can apply before adding any server.

What local and remote mean in MCP

The Model Context Protocol defines how a client (the application hosting the agent) discovers and calls tools, reads resources and uses prompts offered by a server. The specification describes two standard transports, and they map neatly onto the two deployment styles.

• Local (stdio). The client launches the server as a child process and talks to it over standard input and output. The server runs under your user account, sees your filesystem and environment variables, and stops when the client stops.
• Remote (Streamable HTTP). The server is a long-running web service. The client connects over HTTP, authenticates and keeps a session. Someone operates that service: a vendor, your platform team, or you.

Real setups blur the line. A local server often calls a remote API behind the scenes, so data still leaves the machine. A remote server can be one you host inside your own network, which gives you central operation without handing data to a third party. When you evaluate a server, ask two questions separately: where does the server process run, and where does the data it touches end up?

Trust: whose code runs, and with what rights

A local server is code you execute. If you install it with a one-line package runner, you pull whatever version the registry serves at that moment and run it with your own privileges. That is a supply-chain decision, the same kind you make for any dependency: who maintains it, is the version pinned, can you read the source, does it ask for more access than its job needs? A server that only formats dates should not be able to read your SSH keys, yet a local process usually can.

A remote server moves the code off your machine, which removes one class of risk and adds another. You no longer run their code, but you send them inputs and accept their outputs, and you cannot see what happens in between. The tool list and tool descriptions can change on the server side without any update on your end. Because the agent reads those descriptions to decide what to call, a changed description is a changed instruction. Pin what you can, and make sure you notice when a server's advertised tools change.

Both styles share one risk: tool output flows straight into the agent's context. A page, an email or a ticket returned by a tool can contain text written to steer the agent. Transport does not protect you from that; narrow scopes and approval steps do.

Authentication and credentials

Local servers usually authenticate to downstream services with a long-lived key placed in the client's config file or an environment variable. It is simple and it works offline, but the key sits in plain text on every machine that runs the server, it often carries the full rights of whoever created it, and revoking it means hunting down every copy.

For HTTP transports, the specification's authorization section builds on OAuth 2.1: the user signs in, the client receives a token meant for that server, and the operator can revoke it centrally. That model suits teams better, provided the server does its part. Check whether it verifies that tokens were issued for it, whether it avoids passing your token straight through to other services, and whether it offers read-only scopes. A remote server that requests every scope at sign-in has simply moved the long-lived key somewhere you cannot see.

Whichever style you choose, keep one habit: give each server its own credential, limited to the smallest set of actions the work needs, and keep read and write credentials apart so that a read-only setup really is read-only.

Data exposure: map what crosses the boundary

Do not assume local means private. Draw the data flow for one realistic call. What goes into the tool arguments: a search term, a file path, a whole document the agent pasted in? Where does the server send it? What does it log, and for how long? What comes back, and does that response now sit in a model context that is itself processed somewhere else?

With a remote server, everything in the tool arguments leaves your boundary by definition. Agents are generous with arguments; hand one a summarize tool and it will happily send the full text of a confidential file. If a server handles data you classify as internal or restricted, either host it yourself or make sure the work that calls it is limited to data you are allowed to send out.

Latency, availability and operations

A stdio server has no network hop between client and server, starts with the client and keeps working on a plane, as long as the work itself does not need the network. A remote server adds round trips and a dependency on someone else's uptime, but it can sit next to the data it serves, which often matters more than the hop from your laptop. Measure on your own workload instead of assuming either one is faster.

Operations is where the gap is widest. Ten developers running a local server means ten copies, ten config files and, a month later, several different versions. Nobody can answer "who called the delete tool last Tuesday?" A remote deployment gives you one version, one place to revoke access and one log, at the price of running a service: monitoring, upgrades, authentication and incident response, or a dependency on a vendor who handles them.

Choosing between them

• Prefer local for tools that work on your own files or desktop applications, for single-developer setups, for experiments, and when data must stay on the machine and the tool does not call out.
• Prefer remote when many people need the same tool, when access must be granted and withdrawn per person, when you need a single audit log, or when the server must sit close to a shared system.
• Prefer self-hosted remote when you want central operation but the data cannot go to a third party.

For help picking specific servers, see choosing MCP servers for your agent, and for search in particular, choosing a web search MCP server.

Authority is a separate question from transport

Neither transport answers the most important question: should this task be allowed to use this tool right now? Connecting a server makes a tool available. It does not make every use of it appropriate. A sensible setup starts read-only, adds write tools deliberately, and makes consequential calls such as sending, deleting or exporting wait for a person.

GoCux follows that split. It does not publish a hosted MCP endpoint; MCP tools run in your own compatible client, and the customer CLI keeps ownership of its local tools and permissions. Having a server configured does not clear every task to use it, and a registered connector on its own authorizes nothing either. Credentials are held as server-side references rather than in the browser, consequential actions pause until someone on the team decides, and requests, decisions, tool runs and their outcomes form a single trail the team can read. The MCP quickstart shows the setup, and connect tools without widening authority explains the reasoning.

Checklist before you add a server

• Do you know where the server process runs and where the data it touches ends up?
• Is the version pinned, and can you read the source or a changelog?
• Does it have its own credential, scoped to the minimum, with read and write kept apart?
• For remote servers: is sign-in per user, are scopes narrow, and can you revoke access in one place?
• Will you notice if the advertised tools or their descriptions change?
• Which tool calls should wait for a human decision, and where is that enforced?
• Where are calls logged, who can read the log, and how long is it kept?
• Have you started with read-only tools? See start agents read-only.