Inside MCP: Understanding the Client-Server Architecture

Every AI assistant runs into the same problem: how can it safely and reliably reach past its training data to work with APIs, databases, and files? The Model Context Protocol (MCP) has quietly become the answer, and if you're building with AI, you need to understand how it works.

MCP started as a spec for standardizing how large language models talk to outside systems. In under two years, it's turned into core infrastructure. When you use Claude Desktop, Cursor, or any of the growing list of MCP-compatible tools, there's a good chance a small group of clients and servers is swapping structured JSON-RPC messages behind the scenes to power your workflow. Here's how the pieces fit together.

Why MCP Matters Now

Before MCP, hooking an AI model up to an outside system meant custom coding for every case. Each host app built its own plugin system, and every tool provider had to write separate adapters for each host. This wasted effort, created fragile connections, and split the ecosystem so tools rarely worked across different products.

MCP fixes this by giving everyone one open protocol to follow. Write a database connector once, and any MCP-compatible host can use it. Teams building AI assistants don't have to reinvent the wiring anymore—they just speak MCP and instantly tap into a growing library of servers. According to the official specification, this works thanks to a layered design that keeps different jobs neatly separated.

The Three-Tier Structure: Hosts, Clients, and Servers

MCP is built around three distinct components, each with a well-defined role.

Hosts are the AI applications users actually interact with—products like Claude Desktop or Cursor. The host owns the user experience, manages the model, and decides which external capabilities to make available.

Clients live inside the host. Each client maintains a 1:1 connection with a single server, handling the full protocol lifecycle from initialisation through shutdown. If a host connects to five servers, it spins up five clients. As Stanza notes, this one-to-one mapping keeps state management predictable and connection boundaries clear.

Servers are lightweight processes that expose capabilities to clients. A server might wrap a database, an internal API, a filesystem, a SaaS product, or any other system the AI needs to reach. Crucially, servers know nothing about the model or the host—they simply advertise what they can do and respond to well-formed requests.

This separation delivers real benefits: hosts can innovate on user experience, servers can be developed and reused independently, and clients keep the protocol details tidy.

A Two-Layer Protocol: Separating Data from Transport

Alongside the three-component model, MCP splits the protocol itself into two layers.

The data layer defines the messages—what a tool call looks like, how resources are described, how capabilities are advertised, and how notifications flow. It is built on JSON-RPC 2.0 and is entirely independent of how the bytes get from A to B.

The transport layer handles that delivery. It defines the channels over which JSON-RPC messages travel, but it does not care what those messages mean.

This separation is more than architectural tidiness. It means the same server logic can serve local desktop tools and remote cloud deployments without change. It also makes debugging dramatically easier: you can inspect the JSON-RPC exchange without worrying about transport quirks, or troubleshoot transport issues without decoding protocol semantics.

The Three Primitives: Tools, Resources, and Prompts

Every MCP server shows off what it can do through three primitives, and learning them is the quickest way to understand MCP.

Tools are functions the model can run to actually do something—like searching a database, sending an email, creating a ticket, or crunching numbers. Think of tools as the verbs of MCP.

Resources are data the model can read and point to, such as documents, records, files, or any structured content the server wants to share. Resources are the nouns.

Prompts are ready-made templates and instructions the server provides to guide how the model tackles a task. They let the people building the server bake their know-how right into the integration.

As Medium contributor James Aspinwall explains, these three primitives give LLMs a reliable way to find and use outside capabilities—no matter which server they're connecting to.

JSON-RPC 2.0 and the Choice Between stdio and Streamable HTTP

## JSON-RPC 2.0 and Choosing Between stdio and Streamable HTTP

At the data layer, MCP runs on JSON-RPC 2.0, a proven and lightweight standard that handles request/response pairs, notifications, and clear error reporting. Every capability check, tool call, and resource request travels as a JSON-RPC message.

For transport, MCP gives you two choices:

• stdio works for local communication. The host starts the server as a subprocess and swaps messages through standard input and output. It's fast, secure out of the box, and perfect when the server and host live on the same machine.

• Streamable HTTP powers remote, distributed, and cloud setups. You can host servers anywhere, share them across teams, and scale them separately from any host app.

As Knit's technical deep dive points out, this two-transport setup lets teams pick the deployment style that fits their security needs, speed goals, and infrastructure limits—without touching a single line of protocol code.

Capability Negotiation and the Connection Lifecycle

When a client connects to a server, the two do not simply start exchanging tool calls. They begin with capability negotiation: a structured handshake in which each side declares which protocol version it speaks and which features it supports.

This matters because MCP is a living specification. Servers built against older versions must still work with newer clients, and vice versa. Negotiation ensures that both parties agree on a compatible feature set before any real work begins.

Once initialised, the connection settles into a defined lifecycle. Clients can perform dynamic tool discovery—querying the server at runtime to learn what tools, resources, and prompts are available. Requests and responses flow over JSON-RPC. Notifications can be sent in either direction. Eventually, the client shuts the connection down cleanly.

This structured lifecycle also enforces clear security boundaries. Hosts decide which servers to trust. Clients mediate every message. Servers only see the requests they are meant to handle.

What This Architecture Unlocks for Developers

MCP's design gives developers some real, practical wins:

• Standardisation: One protocol links any model to any system.

• Modularity: Build a server once and reuse it across every MCP-compatible host.

• Debuggability: Clear layers and clean boundaries make it easy to spot where a problem is.

• Flexibility: The same server can run locally over stdio or remotely over HTTP.

• Predictability: The three-primitive model gives LLMs a consistent way to interact, no matter what system sits underneath.

For engineering teams, this matters a lot. Instead of building custom integrations for every new AI product, you can expose your internal systems as MCP servers just once—and instantly make them available to every host your organisation uses.

Conclusion

MCP is quietly becoming the connective tissue of the AI application layer. By separating hosts, clients, and servers—and by cleanly splitting the data and transport layers—it turns a chaotic integration problem into a solved one. The three primitives give models a predictable vocabulary. JSON-RPC 2.0 gives developers a well-understood foundation. And the choice between stdio and Streamable HTTP means the same architecture scales from a single laptop to a fleet of cloud services.

If your team runs internal APIs, databases, or bespoke tools, the question worth asking is no longer whether to expose them to AI, but how. Wrapping them as an MCP server may be the highest-leverage integration work you do this year. So here's the thought to sit with: as more of the software world becomes MCP-addressable, what does true AI interoperability look like—and which of your systems will be ready when it arrives?