What is a remote MCP server?

As development shifts toward agentic workflows, an AI agent is only as capable as the systems it can reach. Local MCP servers allow desktop CLI and IDE agents to execute multi-step tasks on your machine. But remote MCP servers (also called hosted MCP servers) extend that reach to cloud-based and background agents, allowing an agent running in a web browser, a CI runner, or a backend service to access external tools over HTTP without needing a developer’s machine running local child processes.

In this post, you’ll learn what MCP is, what makes a server “remote” (or “hosted”), how remote and local servers differ and when to choose each, and how to connect an AI agent to CircleCI through a hosted MCP server.

What is MCP?

The Model Context Protocol is an open standard, introduced by Anthropic in late 2024, for connecting AI applications to external tools and data. Think of it as a common plug. Instead of every AI tool inventing its own way to talk to GitHub, a database, or your CI provider, they all speak MCP.

MCP is not the only way to give an agent access to a system. A purpose-built command-line tool can do the same job, and the trade-offs between an MCP server and a CLI depend largely on whether a human or an agent is driving. This post focuses on MCP, and specifically on where the server runs.

The protocol has two sides:

• An MCP client is the AI application you interact with, such as an IDE assistant, a chat interface, or an autonomous agent.
• An MCP server sits in front of some system and advertises what the model is allowed to do there.

Each server exposes three kinds of capability: tools (actions the model can call, like “fetch the logs for this build”), resources (data the model can read), and prompts (reusable templates a server can offer). The client discovers those capabilities at connection time and hands them to the model, so the assistant acts on real data instead of guessing from its training set.

The key idea is decoupling. Any MCP client can talk to any MCP server, the same way any browser can load any website. That is what makes the local-versus-remote question a deployment choice rather than a rewrite: the protocol is identical, and only the packaging changes.

What makes an MCP server “remote” (or “hosted”)?

The distinction comes down to one thing: where the server runs and how the client reaches it.

A local MCP server runs on your own machine, launched by the client as a child process, and the two talk over standard input/output (stdio). A remote (or hosted) MCP server runs as a hosted service that the client connects to over HTTP, so it lives on the network rather than on any single machine.

“Remote” and “hosted” describe the same thing from two angles. Remote is the client’s point of view (the server is somewhere else, across the network), and hosted is the operator’s point of view (someone runs it as a managed service). You will see the two terms used interchangeably.

Local vs. remote MCP servers

Both kinds of server speak the same protocol and expose tools and resources the same way. What changes is where the server process runs, which AI clients can reach it, and how authentication is managed.

Concern	Local MCP server	Remote (hosted) MCP server
Where it runs	Your machine, as a child process	Hosted service or cloud infrastructure
Transport	stdio (Standard input/output)	Streamable HTTP (POST + SSE)
Setup	Installed and configured per developer laptop	Zero local setup—connect via a URL
Authentication	Local environment variables / local secrets	Centralized sign-in (usually OAuth 2.1)
Updates	Each user updates their local binary/package	Operator updates once; instantly live for everyone
Which clients can connect	Local IDEs and terminal CLIs	Any client, including browser-based agents
Data path	Client <-> MCP server stays local (server may still call cloud APIs)	Client <-> MCP server travels over HTTPS
Scaling	One local user per process	One deployment serves the entire team
Best fit	Local file access, shell scripts, personal laptop tooling	Browser agents, zero-install team setups, centralized org access

Neither option is universally better; the right choice follows your client and deployment needs.

Reach for a local server when your agent runs on your desktop (like Cursor or a terminal CLI) and needs access to your local filesystem, local environment variables, or scripts tied to your machine. You get zero network overhead between the client and the MCP server, and full offline usability for local tasks.

Reach for a remote (hosted) server when you want a zero-install solution for your team or need compatibility with browser-based AI agents (which cannot spawn local stdio subprocesses). Everyone points to a single HTTPS URL, access is managed centrally via OAuth without scattering personal tokens across laptops, and updates take effect instantly for all connected developers.

How a remote MCP server works under the hood

Three things change when a server moves off your laptop: the transport, the authentication, and how state is handled. Understanding these is what separates knowing that remote MCP exists from knowing how to pick one and trust it.

Transport: stdio vs. Streamable HTTP

Local servers use stdio. The client writes JSON-RPC messages to the server’s standard input and reads replies from its standard output. That is simple and fast, but it only works when the client can spawn the process in the first place.

Remote servers use Streamable HTTP, the protocol’s current transport for network connections. It exposes a single HTTP endpoint that handles both directions: the client sends requests with HTTP POST, and the server can stream results back using Server-Sent Events (SSE) when a response arrives incrementally. This replaced the protocol’s original two-endpoint HTTP+SSE transport, which is now deprecated. The single-endpoint design is stateless-friendly, so a remote server can sit behind a standard load balancer or proxy and scale horizontally like any other web service.

Authentication: OAuth instead of local secrets

A local server inherits whatever access your machine already has, typically an API token in an environment variable. That does not translate to a shared service reachable over the internet, so the remote transport standardizes on OAuth 2.1 (with PKCE required).

The flow is the familiar one. The client sends you to the provider’s authorization server to sign in and consent, the authorization server issues a token, and the client then sends that token as an Authorization: Bearer <token> header on every request. The server validates the token and checks that it carries the right scopes before running a tool, returning standard 401 or 403 errors if it does not. Many servers also support OAuth discovery and dynamic client registration, so a client can find the right endpoints and register itself automatically. In practice that means you click “connect,” sign in, and you are done, with no tokens to copy or paste.

State and scale

Because the transport is stateless-capable and access is enforced per token, a single hosted deployment can serve many users at once and be updated in one place. That is the structural reason remote servers fit shared systems: the operator ships an update or tightens a permission once, and every connected client gets it, instead of asking each developer to reinstall a binary.

Seeing the difference in config

The split shows up right in your client’s configuration. A local server names a command to run; a remote server names a URL to connect to:

{
  "mcpServers": {
    "local-example": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"]
    },
    "remote-example": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Config formats vary by client, but the pattern holds: a command means the server runs locally over stdio, and a URL means the client reaches a hosted server over HTTP.

Connecting an agent to CircleCI via remote MCP

Your pipelines already know why a build broke, which test is flaky, and whether the last deploy succeeded. CircleCI offers a hosted MCP server that makes that build knowledge available to any MCP-enabled AI application, allowing agents to pull answers straight from your pipelines instead of requiring developers to manually copy build logs into a prompt.

Because the hosted server runs as an HTTP service in the cloud, there is nothing to install locally. You point your AI application at the endpoint and authenticate with OAuth. In terminal environments like Claude Code, adding the server takes a single command:

claude mcp add --transport http circleci https://mcp.circleci.com/v1/mcp -s user

Any MCP-compatible application can connect using that same URL (https://mcp.circleci.com/v1/mcp). The server handles OAuth 2.1 discovery and dynamic registration automatically, guiding you through sign-in with your CircleCI account.

Once connected, agents can autonomously call CircleCI tools mid-task to answer questions such as:

• “Why did my latest pipeline on this branch fail?”

• “Which tests have been flaky this week?”

• “Summarize the failure logs for job X.”

The agent executes the matching tool call, retrieves the build logs directly from CircleCI, and analyzes the root cause, turning pipeline troubleshooting into an automated, conversational step.

Choosing your CircleCI agent interface

The hosted remote MCP server is one of two agent-friendly surfaces CircleCI provides. Depending on where your AI workflows run, you can choose the approach that best fits your setup:

• CircleCI remote MCP server: Use this when you want zero local installation, centralized OAuth management, or compatibility with web and browser-based AI tools that cannot launch local child processes.

• CircleCI CLI (local MCP & shell): Use this for local terminal and IDE workflows. The CLI can run as a local stdio MCP server on your machine or execute direct terminal commands with predictable --json output and stable exit codes for shell-based agents. Learn more about the CircleCI CLI.

Whether your agent runs in a web browser, an IDE, or a local terminal, it accesses the exact same pipeline data and build context, giving your team flexibility without sacrificing a single source of truth.

Wrapping up

MCP gives AI agents a standard way to reach the tools you already use. Remote (hosted) MCP servers make that reach a team-wide capability instead of a per-laptop setup: they run as a shared service over Streamable HTTP, authenticate centrally through OAuth, and stay open to any client, including agents with no command line. For shared systems like CI/CD, that is the natural fit. Connect once, authenticate centrally, and give every developer’s agent the same real data to work from.

Want to give your AI agent eyes on your pipelines? Sign up for a free CircleCI account and connect your client to CircleCI’s hosted MCP server.