0:01Our stock server now offers tools, a resource, and a prompt. Our app accesses them through its MCP client.
0:08Each time the app asks for something, the server sends a reply.
0:12Let's look at the messages they exchange, so we can see what those requests actually contain.
0:17We'll record a run, then follow three exchanges: discovering the server, listing its tools, and calling one.
0:24Here's our app again. We'll put a small logging program between it and the server, so we can read their messages.
0:32This is the tap. It forwards messages between the two programs and keeps a copy for us.
0:37It starts the server with the command our app normally uses, then opens the log file.
0:41Let's look at how it forwards the messages.
0:45This function copies each line to the other program. It also formats a copy for the log, so the messages are easier to read.
0:52Now let's point our app at the tap.
0:55This is the command our app uses to start the server.
0:57We'll replace it with the command for the tap.
0:60Now the app starts the tap, which starts the server. Let's try a stock-price question.
1:05We're asking for Nvidia's latest price, as before. Let's run it.
1:10The tap is recording the messages exchanged between our app and the server during this run. We get the stock price back as before.
1:16Here's the log it created. Let's open it.
1:21The messages are listed in the order they were sent. Let's start at the top.
1:25The arrow lines tell us which way a message was sent. The text below each arrow is the message itself.
1:32Our app starts by asking about the server. This request has an identifier, and a method that says what it's asking for.
1:39Every message in this log opens with that same line, naming the format both sides speak. This is JSON-RPC. RPC stands for remote procedure call, ask another program to run something, and get its answer back.
1:55There's some information about our app here too: its name, the protocol version it uses, and the capabilities it supports.
2:02Let's look at the reply.
2:04It carries the same number as the request. That's how the app knows which question this answers.
2:09The server tells us which protocol versions it accepts, and that it supports tools, resources, and prompts.
2:15Its name is a little further down.
2:18This is where our app gets the server name it prints when it connects.
2:22In this protocol version, each request includes the client information. There's no separate handshake to establish it first.
2:29The next request includes the client information again. Let's look at what it's asking for.
2:35This time, our app asks which tools are available.
2:38Let's look at one of the entries in the reply.
2:41Here's the tool's name and description. The SDK took that description from the docstring in our server code.
2:48This tells the caller which arguments the tool accepts, their types, and which ones are required.
2:53That's what the app needs to describe a tool to the model. The function's code stays on the server.
2:59The other tools have their own descriptions and argument definitions too.
3:03Now let's look at the request that fetched the price.
3:06Our app asks the server to call a tool. The request includes the tool's name and the arguments to use.
3:13The model chose this tool and the ticker symbol. Our app sends that choice to the server through its MCP client.
3:19Let's look at what came back.
3:21The matching identifier tells us this is the reply to that call.
3:25The server returned the price as text, along with a structured result.
3:29Our app passes this text back to the model so it can answer our question.
3:33Let's bring the answer back into view.
3:35The model used the price returned by the server to write this answer.
3:40So MCP sets the rules for this exchange between our app and the server.
3:44Next time, we'll look at how the client handles these requests for our app.

What Goes Over the Wire

Created by Abhyuday DesaiPublished 2 Oct, v1 of 2Runs 3 min 54 sec

1 view

About this video

In Episode 08 of MCP Explained, we read the actual messages between our app and our server. A small logging program sits between the two, forwards every line, and keeps a copy. Then we walk the log: the request that asks the server to introduce itself, the reply that lists what it supports, the tool list with its schemas, and the call that fetched a price, matched to its reply by an identifier.

You'll learn how to:

Put a tap between a host and a server by changing one command, and record a full run
Read a JSON-RPC request: an identifier, a method, and the sender's introduction carried in every message
See how a reply is matched to its request, and where the app gets the server name it prints
Find the tool description and argument schema on the wire, and confirm the function's code never crosses
Follow a tool call out and its result back, and see the text the model turns into an answer

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

v204 Oct 2026abhydesai3 min 49 sec4e3d69a
Scene 3: the click now sounds when the log file opens, and closing the terminal is silent. Scene 4: the JSON-RPC explanation is two shorter lines, with a bottom bar that expands RPC as Remote Procedure Call. Scene 6: the tool name and arguments get their own highlighted beat; the reply is read whole first, then its identifier line, then the price text; and the answer row in the terminal is highlighted when the model's answer is discussed.

Same chapters. Transcript: 6 of 45 lines changed. 5 sec shorter.
Show the differencesHide the differences
1. Every message in this log opens with that same line, naming the format both sides speak. This is JSON-RPC. RPC stands for remote procedure call, ask another program to run something, and get its answer back.
  
  Every message in this log starts with this line. It names the format both programs use, which is JSON-RPC.
  It means one program asks another to run something and return the result.
2. ~~Our app asks the server to call a tool. The request includes the tool's name and the arguments to use.~~
  
  Our app asks the server to call a tool.
  The request includes the tool's name and the arguments to use.
3. ~~The matching identifier tells us this is the reply to that call.~~
4. The matching identifier tells us this is the reply to that call.
0 views0 likes on this version

Watch v2

v102 Oct 2026abhydesai3 min 54 sec805b43c

First published version.

1 view1 like on this version