Remote MCP Servers: Why 'Just Run It Locally' Stopped Working

The Model Context Protocol was built for a world where the AI agent and the developer sat at the same machine. Once agents started running in browsers, CI pipelines, and backend services with no laptop in the loop, that assumption broke — and remote MCP servers are the fix teams are converging on.

How It Works

A local MCP server runs as a child process on a developer’s machine, talking to the AI client over stdio (standard input/output) using JSON-RPC messages. It works well for one thing: a single person, at their own keyboard, with tools installed and authenticated on that specific machine. Anthropic’s Model Context Protocol, introduced in late 2024, standardizes how an AI application discovers and calls three kinds of capabilities from a server — tools (callable actions), resources (readable data), and prompts (reusable templates) — but the original stdio transport assumes the server and the client are on the same box.

A remote MCP server breaks that assumption on purpose. It’s a hosted service that any client reaches over Streamable HTTP with Server-Sent Events for incremental responses, authenticated through centralized OAuth 2.1 with PKCE instead of local environment variables. CircleCI’s implementation is live at mcp.circleci.com/v1/mcp — an agent running in a web browser, a CI runner, or a backend service connects to that single URL, authenticates once through OAuth discovery and dynamic registration, and can immediately query build data, ask “why did my latest pipeline fail?”, or pull logs for analysis, all without anyone installing anything locally first.

What This Means for You

The practical difference shows up at the team level, not the individual-developer level. A local MCP server needs per-developer installation and per-developer updates — if the tool changes, every laptop needs the new version. A remote server is one deployment that every client hits immediately, and it’s reachable from places a local process never could be: a browser-based agent has no laptop to run a child process on, and a CI runner spinning up in someone else’s cloud infrastructure can’t assume local tooling exists either. That’s exactly the gap CircleCI is targeting — CI/CD systems are, almost by definition, ephemeral and headless, which makes them a natural first use case for the remote pattern even though nothing about MCP itself is CI-specific.

None of this makes local MCP servers obsolete. Local file access, shell scripts, and offline-capable personal tooling are still better served by a process that runs where the files already are — there’s no reason to add a network hop and an OAuth flow to a tool that only ever needs to read files on the machine it’s running on. The distinction to build around is who and what needs access: local for one developer’s machine, remote for anything that needs centralized, team-wide, or non-desktop access.

There’s also a security posture change worth naming. A local server inherits whatever secrets live in that developer’s environment variables, which means credential sprawl scales with headcount — every laptop is its own small attack surface. Centralizing behind OAuth 2.1 with PKCE and dynamic client registration moves that surface to one hardened, monitored endpoint instead, which is a meaningfully easier thing for a platform team to audit than N developers’ local .env files.

Source: CircleCI

Content created with AI assistance and reviewed for accuracy.