0:01Here is where the series stands, one small agent, an MCP client inside it, and the stock server we wrote, all connected.
0:09Both sides of this picture run on one computer. Our app starts the server as a subprocess, and the two talk over that process's standard input and output.
0:19One server in the series was different. The weather company's server, the first one we ever plugged in, did not run on our machine.
0:26Our app reached it across the internet, through a client of its own. The connection worked like the local one, discovery first, then tool calls.
0:35So the protocol already crosses machines. What we have never done is put our own server on the far side of a connection.
0:42That is the move this video makes. Before we make it, it helps to see how little is actually moving.
0:48A request to our server is the same request either way, a method, its arguments, and the sender's introduction. Moving the server changes only how those messages travel. Let's make the move.
1:01This is our stock server, the same file we built earlier in the series, with its three tools, its resource, and its prompt. Nothing in it changes for the move, except the last line.
1:12Here is the change. The run call now names a transport, streamable HTTP. Instead of reading its standard input, the server now starts a small web server and takes requests at an address.
1:23That is the entire server side of the move. The other half is in the agent's folder, let's open it.
1:30This is the agent from before, it hands the model a task, offers the tools it discovers, and serves the calls the model makes. It has not changed either, apart from its server list.
1:42The list still holds one server, but the entry is now an address. There is no command to launch and no subprocess to manage, the client sees an address and connects over HTTP instead.
1:53That is the whole change, one line in the server, one entry in the agent. This pair runs, and brings back the price.
1:59Let's look at what answering at an address asks of a server.
2:04So our server now answers at an address. Two things follow from that.
2:08First, who can call it. As a subprocess, it received requests from one app only, the one that started it. Deployed at a public address, anything that can reach it can send a request.
2:21So identity becomes the server's problem. A real deployment puts a check in front, each request presents a key or a token, or it is refused. Ours has no check yet.
2:31We have seen such a check before, from the other side.
2:34The weather server's address carried a key at its end, and requests without it are refused. We were the caller being checked.
2:41For doing it properly, the mcp package's own answer is OAuth, the permission standard the web already uses. Naming it is as far as this series goes.
2:51Second, memory. The server does not keep track of its callers between requests. Every request carries the sender's introduction, so each one can be answered on its own.
3:01Everything else, scale, timeouts, rate limits, is ordinary web service work. MCP runs over plain HTTP, so none of that is protocol knowledge.
3:12Now take the two servers together. The weather server has answered at an address since our first connection. As of today, so does ours.
3:19So the direction turns around. Put our server somewhere reachable, and any app can add it with one address, the way we added theirs. That is the promise this series opened with, and this move completes it.
3:32So the series has reached its end. Let's look at what you can build now.
3:36You have used servers other people wrote, and built your own. You have seen every message that crosses a connection, and given an agent several servers at once. As of this video, your server can run anywhere.
3:48If you keep two ideas from all of it, keep these. The first, connection work is written once per side, never once per pair.
3:55The second, the custom side is the server. Clients do the same job everywhere, so they come from a package.
4:01MCP connects a model to tools and data, that is its whole job. Agents talking to each other is a different problem, with its own protocol, A-two-A. That is the next series. Thanks for watching.

Going Remote

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

0 views

About this video

In Episode 13 of MCP Explained, our stock server leaves the machine. One line in the server names a transport, streamable HTTP, and one entry in the agent becomes an address. Then we name what a deployed server takes on: identity in front of it, no per-caller memory, and everything else being ordinary web-service work. The series closes with the two ideas to keep, and the boundary between MCP and agent-to-agent protocols.

You'll learn how to:

See how little moves when a server goes remote: the same request, a different way for messages to travel
Make the move in two lines: a transport on the server, an address in the agent
Understand why identity becomes the server's problem at a public address, and what the standard answer is
Learn why the server keeps no memory of its callers: every request carries its own introduction
Take away the two portable lessons of the series, and where MCP's job ends

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 19 sec805b43c

First published version.

0 views0 likes on this version