The Video Assistant · Lesson 9 — The Round Trip ← Course

The round trip — one call, end to end.

Follow a single question all the way through: host, model, MCP, your server, and back.

You have every piece now — a tool, the socket, a server you wrote, and a client hooked up to it. Here they all move at once. Watch one question make the full round trip.

The shape is the same request → run → read from the start of this lesson, but now the boundary is explicit. The app and model sit on one side — the host; your server sits on the other; and MCP is the line between them that the request and the result cross.

Watch who does what. The model only ever forms a request and reads a result — it never crosses the line. Your server does the real work. MCP just carries the messages between them, in a shape both sides agree on.

Step through one appeal and follow it across: out to your server, and back with a grounded answer.

Step 1 of 6
host · client
app + model
◀ MCP ▶
your server
match-stats

Request out, result back.

One question, one round trip: the model forms a request, the client carries it across MCP to your server, the server does the work, and the result returns for the model to answer from. The same ask-run-read loop from the first page — now split cleanly across a standard boundary.

That boundary is the whole point of MCP: the model side and the tool side can be built by different people, in different languages, and still fit together — because every message crossing the line follows one shared protocol.

Next: the away fixture →
▸ Go deeper — what crosses the line optional

The model never crosses the line

The model only emits a request and reads a result — both are just text on the host side. It cannot reach your server directly; the client mediates every message. That gap is your control point: the client decides which requests to honour before anything runs.

One shared shape

The request and result travel in a format both sides agree on (JSON-RPC, under the hood). That agreement is exactly what lets a Python server and a completely different client — even from another vendor — understand each other without custom glue.

It composes into a loop

A real agent may make this round trip many times over: call a tool, read the result, decide the next call, and so on until it is done. That repeated loop — think, act, observe — is the whole of the next lesson.

Time and failure are real

Every round trip costs time, and a tool can be slow or fail outright. Good clients set timeouts and pass errors back so the model can react rather than hang — the wrong-footage caution from the last lesson, now at the scale of live tool calls.