MCP Fundamentals: Hosts, Clients, Servers and the JSON-RPC Wire Format

Language models became genuinely useful to businesses the moment they could act, not just answer. The hard part has never been the model itself; it has been wiring it to the databases, APIs and internal tools where the work actually happens, and doing that wiring once instead of once per application and once per model vendor. The Model Context Protocol (MCP) is an attempt to standardize that wiring. This article explains the problem MCP solves, the roles of its components, what travels over the wire, and how the two standard transports differ, so you can reason about where an MCP server fits in your own architecture.

Where LLMs create value: taking actions

A great deal of automation used to be out of reach simply because software could not interpret loosely structured requests. Language models remove that barrier, and once they are connected to tools they can drive multi-step workflows that previously required a person to hop between systems.

Consider an assistant asked to find and book a train from Casablanca to Rabat. Understanding the request is only the first step. The assistant must search a timetable service, pick a departure, call a booking API and confirm the result. Each of those steps is a tool call. When the tools are exposed through an MCP server, any compatible agent can perform the whole flow.

The business case follows directly: fewer manual steps per task means lower operating cost and faster turnaround. There is also a user-experience argument. Employees routinely juggle many dashboards and interfaces, each with its own logic. A conversational front end connected to those backends can hide much of that complexity behind a single interface.

The integration problem MCP addresses

Tool use is not new. Every major LLM SDK supports it, but each one does so with its own conventions for declaring a tool, describing parameters and returning results. The practical outcome is that the same tool gets implemented several times, once per model provider. Switching models, or supporting two at once, means porting that integration code, which slows teams down and makes products harder to scale.

Skipping the SDKs does not fully solve this. You can write your own integration layer that maps intents to actions, calls endpoints, collects parameters, handles errors and records analytics. That is extra complexity, but it is manageable. The deeper issue is that such a layer usually lives inside one application. When a second application needs the same tools, the team rebuilds the same layer again. The integration logic is coupled to the consumer instead of to the system that owns the capability.

What MCP is

MCP is an open standard that gives AI applications a common way to connect to data sources and tools. It does not enable anything that was strictly impossible before; it makes those connections simpler and more consistent. The protocol's documentation at modelcontextprotocol.io is the authoritative reference.

The key shift is where the tool logic lives. With MCP, a backend service such as a database, an API or an internal tool publishes its capabilities through an MCP server. The analogy commonly used is a USB-C port: the service exposes a standard socket, and any compatible application can plug into it. The AI application no longer contains the knowledge of how to use each tool; it only needs to speak the protocol.

The architecture: hosts, clients and servers

MCP uses a client-server architecture with three roles that are easy to confuse:

• Host: the AI application itself, for example a chat assistant, an IDE with an agent, or your own agent service. It is what the user interacts with, and it connects to the outside world through one or more MCP servers.
• Client: a component inside the host that establishes and maintains the connection to a single MCP server. This is the "plug" in the USB-C analogy.
• Server: a program that offers capabilities to clients in a standardized way.

The host never talks to a server directly. It creates one client per server and delegates all communication to it, and each client holds a dedicated one-to-one connection. This separation is useful in practice: a host connected to a file-system server, a ticketing server and a CRM server runs three independent clients, so a failure or permission boundary on one connection does not leak into the others.

The three server primitives

Primitives define what each side can offer. A server exposes three main kinds:

• Tools: operations the model can execute, such as calling an API or writing a record.
• Resources: data the model can read and use as context, such as database rows or documents.
• Prompts: predefined instruction templates that guide the model, similar in spirit to reusable system prompts.

The distinction between tools and resources matters for safety and design. Reading a resource should be free of side effects, while invoking a tool may change the world, so hosts often apply different approval rules to each.

JSON and JSON-RPC: the message format

JSON (JavaScript Object Notation) represents structured data as text built from key-value pairs, arrays and nested objects. Because the format is simple and universally supported, a sender and a receiver written in different languages can agree on what a message means.

JSON-RPC builds on that by defining a fixed message shape for remote procedure calls. A request names a method, carries parameters, and includes an identifier; if both sides respect the structure, the client can ask the server to run a method and receive the result, or an error, in an equally predictable format. The example below is a JSON-RPC 2.0 request asking a server to run a weather lookup for Casablanca. Notice the four fields: the protocol version, a request id used to match the response, the method name, and the params object.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "get_weather",
  "params": {
     "city": "Casablanca"
   }
}

This example illustrates plain JSON-RPC. In MCP itself, tools are not invoked as top-level methods named after the tool. Instead, the client sends a request with the method tools/call, placing the tool name and its arguments inside params. That indirection is what lets MCP define a fixed vocabulary of protocol methods while servers remain free to expose any tools they like.

Discovery is the missing piece

JSON-RPC on its own leaves one problem open: a client must already know which methods a server offers. MCP closes that gap by standardizing how clients discover capabilities. A client can ask a server to list its tools, resources and prompts, receiving names, descriptions and input schemas, and then pass those descriptions to the model. MCP also specifies how the connection is initialized and which transport mechanisms carry the messages.

Transport mechanisms: how messages travel

JSON-RPC defines the vocabulary; the transport defines how bytes move between client and server. At the time of writing, MCP specifies two standard transports. Check the current specification before relying on details, since the protocol continues to evolve.

stdio for local tools

With the stdio transport, the client launches the MCP server as a child process. The server reads incoming messages from its standard input and writes responses to its standard output. Every process gets these pipes from the operating system automatically, so no network socket or port is involved.

This makes stdio a natural fit for tools that run on the same machine as the host, for example a server that creates folders on the local file system. A side benefit is isolation: the server exists only as long as the host keeps it running and is not reachable from the network.

Streamable HTTP for shared, remote servers

With Streamable HTTP, the server is an independent process running as an HTTP service, and it can serve many clients at once. Messages are exchanged over ordinary HTTP requests.

This transport can stream. Rather than waiting for a complete response, the server may send data progressively, which is valuable for long-running tool calls. Streaming is achieved with Server-Sent Events (SSE), a one-directional channel in which one long-lived HTTP response carries a sequence of server-pushed events. Traffic in the other direction still goes out as ordinary HTTP requests from the client. How this behaves in detail depends on the implementation and the HTTP version in use.

A practical rule of thumb: choose stdio when the tool belongs to one user's machine, and choose Streamable HTTP when a capability should be shared across users or teams, with the authentication and network controls that shared services need.

Why a protocol matters more than another SDK

Protocols exist so that systems built by different teams, in different languages and on different release schedules can still interoperate predictably. A protocol is an agreed set of rules for how independent components communicate, interpret each other's messages and establish trust.

The value of standardizing tool access is mostly economic. When the integration cost for a new model or a new application approaches zero, experimenting becomes cheap, and cheap experiments lead to faster iteration. The team owning a system can publish one MCP server, and every current and future AI application in the organization can use it without bespoke glue code. For a look at how this plays out inside an agent framework, see our article on standardizing tool integration in LangGraph with MCP.

Key takeaways

• LLMs deliver the most value when they can act on real systems, and the bottleneck is integration, not intelligence.
• Without a standard, the same tool is reimplemented per model SDK and per application; MCP moves that logic to a server owned by the system that provides the capability.
• A host runs one client per server, and each client keeps a dedicated connection; servers offer tools, resources and prompts.
• JSON-RPC provides the message shape, while MCP adds a fixed method vocabulary, such as tools/call, and capability discovery.
• Use stdio for local, single-user tools and Streamable HTTP for shared remote services, and verify transport details against the current specification.