Every MCP setup, no matter how many tools are involved, is built from exactly three kinds of pieces: a host, one or more clients, and one or more servers. Once you can point at which part of your system is which, the rest of MCP - transports, primitives, auth - is just detail layered on top of this one picture.
The Host
The host is the AI application the person is actually using - Claude Desktop, Claude Code, an IDE with an AI assistant built in, or a custom agent app someone built with LangGraph or another framework. The host is where the LLM lives, where the conversation happens, and where the decision to call a tool gets made. The host doesn't talk to MCP servers directly - it delegates that job to clients.
The Client
Inside the host, an MCP client is created for every server the host wants to talk to - it's a 1:1 relationship, one client per server connection. The client's job is narrow and mechanical: manage the connection to one specific server, handle the message exchange for that connection, and keep it isolated from the host's other server connections. If Claude Desktop is connected to a filesystem server, a GitHub server, and a Postgres server, it's running three separate clients under the hood, one per connection, even though the person just sees "three tools available."
One host, three tools connected, three clients running underneath - each client talks to exactly one server.
The Server
The server is the piece that does the actual work: it wraps a data source or a system - a filesystem, a database, a SaaS API, an internal tool - and exposes what it can do in MCP's standard vocabulary (covered in the next guide: tools, resources, and prompts). Servers are typically built and maintained independently of any specific host. A GitHub MCP server, for example, is built once and works identically whether it's plugged into Claude Desktop, Claude Code, or a custom LangGraph agent - the server has no idea, and doesn't need to know, which host is on the other end.
Local vs. remote servers
Servers can run in two very different places, and MCP is designed to handle both the same way from the client's perspective:
Local servers run as a process on the same machine as the host - a filesystem server, for instance, has no reason to run anywhere else. These typically communicate over stdio (standard input/output), which is simple, fast, and requires no network setup at all.
Remote servers run elsewhere - a company's internal API server, or a hosted third-party service - and the host connects to them over the network, using the Streamable HTTP transport (the current spec's replacement for the older SSE-based transport). Remote servers commonly sit behind OAuth, since they're often gatekeeping real production data rather than files on your own disk.
Multiple servers, one conversation
This is the part that makes MCP feel powerful in practice: a single host can hold connections to several servers at once, and the model can draw on all of them within one conversation - reading a file from the filesystem server, checking an issue on the GitHub server, and querying the Postgres server, all in service of one request, with the host coordinating which client to route each tool call through.