0:01Here is where the series stands. The server on the right is ours, over the last three videos we built its tools, its resource, and its prompt.
0:09When our app runs, requests cross to the server and answers come back, following the rules of the protocol.
0:14The sending and receiving on the app's side happens inside its MCP client. That client is code too, and we never wrote it.
0:22So how much code does it take to speak the protocol, and who ended up writing ours?
0:28To see who writes each part, let's add more servers.
0:31Suppose our app also wants weather data, and files. Each of those comes from its own MCP server, and somebody writes each one around their own data.
0:40For each new server, the host adds another MCP client of its own.
0:43Now each client holds one connection, and our app can reach all three servers the same way.
0:49The servers themselves have nothing in common beyond the protocol. Each one holds different code and different data, and belongs to a different owner.
0:57So that side is always custom work.
0:59The clients all do the same job. Each one packages a request, sends it to its server, and matches the reply that comes back.
1:07Those same three steps, whichever server is on the other end.
1:11A job that is identical everywhere only needs to be written once. That is why the client comes from a package, for us that is the mcp package, the Python SDK for the protocol.
1:24You would not normally write one of these, but it is worth reading one to see what is inside. A complete client, thirty five lines and no SDK, sitting in the same folder as our server.
1:36These three lines are the sender's introduction. Every request will carry the protocol version this client speaks, its name, tiny, and any extras it supports. Ours has none.
1:47The request itself is a plain dictionary. A number for matching the answer, the method being asked for, its parameters, and that introduction tucked inside.
1:58Sending it is one line of text out, the whole dictionary, written as a single line. The reply is read back the same way, one line in.
2:06Then one check. The number on the reply must match the number on the request, so this answer belongs to this question. That is everything a client does per request.
2:16The rest of the file uses that function three times, let's look at them.
2:20This is the client's whole session. It asks the server to introduce itself, asks for the list of tools, and calls one, all with the function we just read.
2:29These same messages have crossed for real before. In the last video we put a wiretap between our app and this server, and kept the log of a full run.
2:39This is that log.
2:40The arrow lines are the tap's notes. Between them, each message from the run, unfolded to read.
2:46The first message of the run, a number, a method, and the sender's introduction. Every field in it is one that our small function fills in.
2:55This log came from our real app, so the sender here is the package's client, and it calls itself mcp. That name is the only field our file fills in differently.
3:05Ours introduces itself as tiny. Run this file through the same tap, and the log would read the same, field for field, with tiny where mcp is.
3:14So the whole working client is thirty five lines. Our own app does something simpler still, let's look at it.
3:21This is our host app. It takes a question, offers the model the server's tools, and serves the calls the model makes.
3:29Its whole client side is this line. It hands the package's client the server's address, and everything we just read happens inside.
3:37That is the division of labor in MCP. The server side is yours to write, because it wraps your data and your rules. The client side is the same job everywhere, so it comes ready made.
3:49The package's client also covers what our thirty five lines left out. It holds several requests open at once, receives a server's notifications, handles errors, and connects locally or over HTTP.
4:01Next time we connect this to a real agent. The app hands the model its tools at run time, and the model decides which ones to call.

You'll Never Write an MCP Client

Created by Abhyuday DesaiPublished 2 Oct, v1Runs 4 min 14 sec

1 view

About this video

In Episode 09 of MCP Explained, we ask who writes the client side of a connection, and why it is not you. Servers are custom: each one wraps different code and data and belongs to a different owner. Clients do the same job everywhere: package a request, send it, match the reply. We read a complete hand-written client, thirty five lines with no SDK, and check its messages against the log from the last video, field for field.

You'll learn how to:

See the asymmetry drawn on the series' own picture: three custom servers, three identical clients
Read a working client in thirty five lines: the introduction, the request dictionary, one line out, one line in, and one check
Confirm the hand-written messages match the real run recorded by the tap
Understand what the package's client adds: concurrent requests, notifications, errors, and both transports
Keep the division of labor: the server side is yours to write, the client side comes ready made

This video is for developers comfortable with Python and calling a model API. Every command is shown on screen and runs from the companion repo.

What changed

v102 Oct 2026abhydesai4 min 14 sec805b43c

First published version.

1 view1 like on this version