A developer guide lays out the trade-offs between running a Model Context Protocol (MCP) server on a workstation and hosting it as a shared HTTP service. The author argues that the choice determines latency, credential exposure and how easily a team can scale the AI-driven data-access layer.

Why the decision matters

MCP is the bridge that lets large-language-model assistants such as Claude or Cursor issue SQL against a database without ever seeing the password. The assistant calls a tool, the tool forwards the request to an MCP server, and the server runs the query. If the server sits on a developer’s laptop, the round-trip is essentially a local function call. If it lives on a central host, every request traverses the network and is subject to the host’s authentication and logging mechanisms. Teams that move from a single-developer prototype to a production environment must decide which model fits their security posture, performance expectations and operational overhead.

The two deployment models

Local (stdio)

The client spawns the MCP server as a child process and talks to it via standard input / output. No network stack is involved.

  • Ideal for: individual developers, quick experiments, and local-only test databases.
  • Advantages: latency is virtually nil; the process inherits the user’s environment, so passwords never leave the machine.
  • Drawbacks: each user must maintain their own configuration file or environment variables; there is no central audit trail; scaling to multiple users requires replicating the setup on every workstation.

Remote (HTTP)

The server runs continuously on a host reachable over HTTP. Clients authenticate, usually with an OAuth-style flow, and send requests to a well-known endpoint.

  • Ideal for: teams, CI pipelines, and production data that must be accessed by several people or services.
  • Advantages: a single point for audit logs, role-based access control, and connection pooling; credentials are stored once in a controlled vault.
  • Drawbacks: additional infrastructure to provision and maintain; network latency adds a few milliseconds per round-trip.

Head-to-head comparison

Aspect Local Remote
Intended usage One user Many users
Authentication Environment variables or local config OAuth-compatible token flow
Auditing None built in Central log records every request
Setup complexity Minimal Requires server provisioning, TLS, token management
Latency Near-zero Higher due to network hop
Credential exposure Confined to the developer’s machine Centralised, but must be protected against breach

A pragmatic hybrid approach

Most organisations do not pick one model and stick with it forever. The guide recommends a staged rollout:

  1. Develop locally – spin up a local MCP server against a sandbox database. The speed encourages rapid iteration and keeps secrets out of version control.
  2. Graduate to remote – once the codebase is shared, move the server to a central host. Switch the client configuration to point at the HTTP endpoint and enable OAuth.
  3. Guard production – keep production databases behind a remote, auditable gateway. Enforce read-only roles for the AI assistant and store production passwords only in a secrets manager that the remote server can access.

Common pitfalls to avoid

  • Storing production passwords in a developer’s .env file or other local config. If the machine is compromised, the database is exposed.
  • Deploying a remote MCP server without an OAuth or comparable token system. Plain-text basic auth or static API keys are easy to leak.
  • Granting the AI assistant write permissions on production tables. Even accidental DELETE statements can cause data loss; a read-only role eliminates that risk.

When local still makes sense

If a team’s workflow never leaves a single machine—think a solo data scientist prototyping on a personal laptop—local deployment remains the simplest, fastest option. The overhead of setting up TLS certificates, token issuance and a logging pipeline may not be justified for a short-lived experiment.

Bottom line

If you need raw speed and are the only user, a local MCP server is the most straightforward choice. If you need auditability, shared access or production-grade security, a remote HTTP server is the only viable path. Most teams start local for convenience, then transition to a remote, token-protected gateway before touching production data. Match the deployment model to the project stage and the risk profile of the data you expose.