How Claude Code connects to MCP tools on your laptop or on a remote server

Two official ways to connect

MCP, the Model Context Protocol, is an open standard for letting an AI app use outside tools. Before an assistant can use any tool, it needs a way to exchange messages with the server that offers it. The standard calls that channel a transport. As dev.to reported in the third part of a Claude Code series, the specification defines exactly two of them.

The first is stdio, short for standard input and output. The assistant starts the tool server as a child process on the same machine and talks to it through those basic text streams. The second is Streamable HTTP, where the server sits at a web address and the assistant sends it requests over the network.

Both carry the same kind of message, written in a format called JSON-RPC (a simple way to ask another program to do something and get an answer back). That is deliberate. What a server offers does not depend on how the bytes travel.

Local process versus remote endpoint

With stdio, the assistant owns the lifecycle. It launches the program, and if the program exits, the connection disappears with it. Standard output is reserved for protocol messages only, while the error stream stays free for logs. This suits scripts and tools that need direct access to your computer, with no network in between.

Streamable HTTP is the standard remote option. The server may answer with an ordinary reply or open a stream of events (SSE, a way for a server to keep sending updates over one connection). Because the server is a web endpoint, it can be deployed separately, protected with authentication, monitored and shared by many clients.

The article puts it neatly: the boundary between client and server becomes a network boundary. That is why moving from local to remote is more than a settings change. Someone has to run the service and decide who may use it.

Streamable HTTP replaced an older HTTP-plus-SSE design from the 2024-11-05 revision of the protocol. The current specification keeps a compatibility path, but new servers are expected to use the newer approach.

What Claude Code adds on top

The two standard transports are the portable baseline, but a client can support more. Claude Code's public documentation lists four kinds of server you can configure:

• a local stdio program;
• a remote HTTP server (a configuration file may also call this type streamable-http);
• a remote server using the older SSE style;
• a remote server over WebSocket, a long-lived two-way connection.

The older SSE option exists because some services still offer only that kind of endpoint. Claude Code labels it deprecated and suggests HTTP where possible. WebSocket can help when a server needs to push events on its own, but the docs recommend plain HTTP when a simple request and response is enough.

The author's advice for anyone building a server meant to work with many clients is to stick to stdio and Streamable HTTP. Extras inside one client are not guaranteed to exist in others.

There is also an in-process case, where the tool lives inside the assistant itself and no process or network is involved. It still presents the same MCP-style interface, so the rest of the client does not need special logic for built-in, local and remote tools.

Why failures look different

The choice of transport changes what a broken connection means. If a local server fails to start or exits, the cause is usually on your machine: a missing program, wrong arguments, a bad environment setting or a crash. Claude Code does not automatically retry a first stdio connection that fails. In an interactive session the server is flagged as failed, and you can reconnect through the /mcp command.

A remote server can be perfectly healthy while the network hiccups. So Claude Code retries. If a connected remote server drops, it makes up to five reconnection attempts, waiting longer each time and starting from a one-second delay. If the very first HTTP or SSE connection fails for a temporary reason, it tries up to three times. Those first-connection retries do not apply to stdio or WebSocket.

Errors like failed authentication or a missing endpoint are generally things to fix, not to retry. The practical lesson from the piece is to treat the transport as part of the diagnosis, not just a line in a configuration file.

What comes next in the series

Once a server is connected and has introduced itself, it can declare a tool such as create_issue. The next installment will cover how that server-side name becomes an entry the model can actually call, and how name clashes between servers are avoided.

For now, the takeaway is a clean division of labor. The transport moves messages, the protocol gives them a common shape, and later layers decide which tools the assistant sees.