Last week, in What Is MCP?, we established the big idea: MCP is the “USB-C port for AI” — an open standard that lets AI applications plug into your systems without a custom integration for every pair. That’s the why. Today is the how: when Claude reaches out and touches your Salesforce org, what machinery is actually moving?
The answer is three parts with three names: the Host, the Client, and the Server. The names sound interchangeable at first — everything in software is a client or a server, it seems — so let me give you an analogy I’d use in a classroom, then map each piece precisely.
The analogy: a hotel concierge
Picture a good hotel.
You, the guest, talk to one person: the concierge. You say “I’d like theatre tickets tonight and a table for two afterwards.” The concierge doesn’t own a theatre or a restaurant. What the concierge has is a phone line to each — one line to the box office, one line to the restaurant — and the judgment to know which line serves which request.
On the other end of each line is a specialist: the box office knows seats, the restaurant knows tables. Each speaks only about its own domain.
Now the mapping:
- The Host is the concierge desk — the AI application you’re actually talking to.
- Each Client is one dedicated phone line — one connection from the Host to one specialist.
- Each Server is a specialist on the other end — a program that fronts one system and offers its capabilities.
And you, the guest, remain in charge: the concierge proposes (“shall I book the 7pm show?”) and you approve before money changes hands. Hold that thought — it’s exactly where consent sits in MCP.
The Host: where you and the model live
The Host is the AI application itself — Claude Desktop, claude.ai, or your IDE, for example. It’s the thing with a window you type into. The Host contains the model’s conversation, decides which MCP servers to connect to, and — critically — owns the security boundary. When a consequential action is about to run, it’s the Host that stops and asks you first.
When I connected my custom Apex tools to Claude (the project I mentioned in part 1), Claude was the Host. My org didn’t talk to “the model” directly; it talked to a Host application that manages the model, the connections, and my approvals in one place.
The Client: one line per server
The Client is the piece beginners usually haven’t heard of, and honestly, you’ll rarely touch it — but knowing it exists makes the diagram make sense.
Inside the Host, there is one Client per Server — a dedicated connector that maintains a one-to-one connection with a single MCP server. If your Host is connected to a Salesforce server, a GitHub server, and a file-system server, there are three Clients inside it, each holding one line open.
Why bother with this separation? Isolation and clarity. Each line is independent: one server going down doesn’t tangle the others, and each server only ever sees its own conversation. The concierge doesn’t merge the box-office call with the restaurant call.
The Server: the specialist in front of your system
The Server is where your work as a builder happens. An MCP server is a small program that sits in front of something real — a database, an API, a Salesforce org — and exposes what it can do in the standard MCP shape, so any Host can discover and use it.
The good news: you don’t build this from raw sockets. The official Python and TypeScript SDKs handle the protocol plumbing; you write the interesting part — “here’s a capability, here’s what it does, here’s the code that runs.” When I exposed Apex to Claude, the server was the translator standing between the MCP world and the Salesforce world. (What exactly a server offers — tools, resources, prompts — is next week’s whole topic.)
The wire: JSON-RPC
So the Host’s Client and the Server are connected. What travels down the line?
JSON-RPC — a simple, decades-old convention for sending messages as JSON. One side sends a request (“call this method, with these parameters, and here’s an ID so you can match your reply to my question”), the other sends back a result carrying the same ID. A request looks roughly like this:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "create_case",
"arguments": { "subject": "Login issue", "priority": "High" }
}
}You don’t need to hand-write these — the SDKs do it — but I want you to see one, because it demystifies the whole protocol. There’s no magic on the wire. It’s labelled envelopes of JSON going back and forth. If you’ve ever called a REST API from Apex, you already have the right instincts.
Two ways to run the line: stdio vs remote HTTP
One practical fork in the road: where does the server live?
Local, over stdio. The Host launches the server as a small program on your own machine and they talk through standard input/output — the same humble pipes command-line tools have used forever. No network, no ports, no server hosting. This is the natural fit for servers that touch your machine (your files, your local tools) and it’s the easiest way to start: write a script, point Claude Desktop at it, done.
Remote, over HTTP. The server runs somewhere else — a cloud service, a company server — and the Host connects over the network. This is the fit for shared systems: one team hosts a server in front of an internal API, and everyone’s Host connects to the same place.
My rule of thumb for beginners: stdio to learn, HTTP to share. Your first server should be a local one, because the feedback loop is minutes, not deployments.
Where consent sits — and why it sits there
Now the part I’d underline twice on the whiteboard.
The Server can offer an action. The model can decide it wants to run it. But before anything consequential happens, the Host asks the user for consent. The approval step lives at the Host — the one place that sees everything and answers to you.
That placement is deliberate. If consent lived at each server, every server author would implement it differently (or forget to). At the Host, there’s one consistent gate in front of every line. When my Apex tools were wired up, Claude could propose invoking them — and I clicked approve, every consequential time. The concierge always asks before booking.
The whole picture in five lines
Let’s compress today into something you can recall on demand:
- The Host is the AI application you talk to (Claude Desktop, claude.ai, an IDE). It owns the conversation and the consent gate.
- Inside it, one Client per server holds a dedicated one-to-one connection.
- Each Server fronts one real system and offers its capabilities in the standard shape.
- They speak JSON-RPC — plain, labelled JSON messages.
- The line is stdio for local servers or HTTP for remote ones.
Your next step
You now know who does what. The natural next question is what, exactly, a server puts on the table — and MCP’s answer is three primitives with pleasingly plain names: Tools, Resources, and Prompts. That’s next Friday, with a Salesforce example for each one. If you missed the foundation, start with What Is MCP? — and the full spec, as always, lives at modelcontextprotocol.io.