How to run MCP servers: local, remote, and hosted
Operate the [MCP](/mcp) servers your agents depend on deliberately — the right ones local, the shared ones run like production services, every credential accounted for, and a catalogue of what runs where.
Before you start
- At least one MCP server in use or about to be — see the build guide if you are starting from zero
- A secrets manager, or at minimum a policy on where server credentials may live
- Knowledge of which agents and people will call each server — the answer drives every deployment decision
Steps
- 1
Decide local or remote per server, on three questions
Who calls it — one person's client, or many agents? Where must the credential live — a laptop, or custody you control centrally? How sensitive is what it touches? One user, low blast radius: run it local over stdio, as a child process of the client. Multiple consumers, central credential custody, or anything regulated: it is a remote service, with everything that implies. Deciding per server beats a blanket policy, because the answers genuinely differ between a filesystem helper and a database gateway.
- 2
Run local servers like packages, not pets
Pin versions in client configuration rather than tracking latest, distribute known-good config centrally instead of letting each laptop hand-edit JSON, and treat installation as the supply-chain decision it is — an MCP server is code that runs with the credentials you hand it, so an unvetted community server is an unvetted dependency with your API keys. Maintain a short allowlist of reviewed servers and versions; everything else gets reviewed first.
- 3
Stand up remote servers like any production service
A remote MCP server is an exposed network service and gets the standard treatment: TLS, real authentication — OAuth is the protocol's answer for user-facing flows, mutual auth or signed tokens for service-to-service — health checks, deployment pipelines, and a rollback path. Nothing about the protocol exempts it from your existing service standards; the failure pattern is treating it as a dev tool that happens to be reachable.
- 4
Centralise credential custody
The server holds the target-system credential, sourced from your secrets manager — never baked into client config, environment files on laptops, or the repository. Scope it to what the server's tools actually do, and where the server acts for different users or agents, resolve their authorisation per session rather than wielding one god-token whose audit trail says only "the server did it". Rotation should be possible without coordinating every client.
- 5
Test the server before clients depend on it
Exercise each tool directly — the MCP Inspector exists for exactly this — then watch a real agent use the server on real tasks, because agents call tools in sequences and shapes you will not have predicted. Keep a small contract-test suite per tool: valid calls, malformed parameters, oversized results, and the error paths. Run it on every server upgrade, since a changed tool description is a behaviour change for every agent downstream.
- 6
Monitor invocations and cap what a call can do
Log every tool call with its caller, parameters, and result size; alert on novel patterns — a tool suddenly called a thousand times an hour, or in combinations never seen before — because an agent misbehaving shows up in its tool traffic before it shows up anywhere else. Add server-side limits: rate caps per caller, result-size ceilings, timeouts. The server is the one place these bounds can be enforced regardless of which agent is calling.
- 7
Catalogue what runs where
Keep a registry of every MCP server in use: owner, version, deployment (whose laptop, which cluster), target system, credential scope, and which agents depend on it. Review it on a cadence and retire what nothing calls. The catalogue is what turns "some agents can reach the finance system from somewhere" into an answerable question — and it is the input you will want when a server credential leaks and you need the blast radius in minutes.
Common pitfalls
- The temporary laptop server that becomes infrastructure — three teams now depend on a process that dies when one person closes a lid, and nobody noticed the dependency forming.
- One shared remote server, one god credential. Every caller inherits full access, and the audit trail can no longer attribute actions to an agent — exactly the shared-service-account mistake, re-created at the tool layer.
- Tracking latest instead of pinning. A server update rewrites tool descriptions, tool descriptions steer model behaviour, and agent output changes overnight with no code change on your side.
- Vetting the protocol but not the package. Teams who would never add a random dependency will install a random MCP server, though it is the same act with credentials attached.
- Testing tools one at a time and never the agent's actual sequences. Single-call tests pass while the failure lives in call ordering, pagination across calls, or context overflow from accumulated results.