0:01We've built our own MCP server and connected an agent to it, that part is done.
0:05The rest of the series is about using MCP in the real world. We'll build some of it, and explain the rest.
0:11Here is where the last video ended. We handed an agent a task, it used three servers to finish it, and its last call wrote a briefing file onto our disk.
0:19That write was an ordinary tool call. The model chose the file server's write tool, the client passed the call across, and the server created the file.
0:27Every step worked as designed, and the whole run went by without asking us to allow anything.
0:32These choices are left to the host, and the host is us. There are three, and this video takes them in order. Let's start with the code.
0:42This is our agent from last time, one file that connects to three servers and lets the model call their tools. Let's start with the first decision, whose code we chose to run.
0:51The choice of servers is all made in this list, one entry each. Ours is first, then a weather company's remote server, then a community file server. Adding an entry connects it and hands its tools to the model.
1:04The third entry is the one to study. It fetches a file server package published by the MCP community, and runs it as a process on this machine. We never opened its code.
1:15The one safeguard is the last argument on the line, a single folder for it to work in, and it refuses paths outside that folder. Handing a server only the access it needs is called least privilege.
1:25And that folder is the workspace on screen, the one this agent runs in.
1:29And our own API key is in that folder, in the file the app reads at startup. Even the one folder we allowed holds a secret.
1:36The folder limit itself is enforced inside the server's own code, the operating system lets this process touch anything our account can. The real protection was the decision to add this server at all.
1:47The second decision is about the calls. Let's read the part of the app that serves them.
1:51This serving loop is unchanged from our first host app. Each turn the model either answers and we stop, or it names a tool it wants called, with arguments.
2:01When it names one, this is everything that happens next, the app finds the owning client, sends the call, and returns the result. There is no approval step in between. The model's decision executes as written.
2:15That gap matters because of what kind of offer a tool is. By design, resources are read by the app, and prompts are chosen by the user. Tools are the one offer the model invokes on its own, when a tool runs, the model is acting on the world.
2:29The specification addresses this directly. The host must get the person's go ahead before any tool runs, and the protocol cannot enforce that itself. Hosts that follow it put an approval prompt exactly in the gap we just read.
2:44That prompt is missing from our agent, fine for a demo we watched, a real decision for anything running unattended. One decision left, what the servers send back.
2:56This return path is the last decision, and it is the easiest one to miss.
3:01Every tool call is a round trip. The request goes out through the client, and the result comes back the same way, into the app.
3:09The app adds each result to the conversation it holds for the model. From then on, that text is context, and the model reads it the same way it reads our task.
3:18And that text is not ours. The stock server is the one we wrote ourselves, and even its answers carry outside text.
3:25Its news tool returns headlines from the public internet, text written by people we know nothing about, straight into that conversation.
3:33Now put the two halves together. The model reading that text is the same model holding every server's tools.
3:39So text can steer it. A planted line could tell the model to read the key file and repeat it. The file server would serve that read, the file is inside its allowed folder.
3:50This is prompt injection. The safe stance is to treat what a server sends back as data to check, never as instructions to follow. That is the third decision. Let's put all three together.
4:02Trusting a server is a decision, and it belongs to us as the host. The protocol connects the pieces, it does not vet them for us.
4:09You are running someone else's code, so know whose, and give it only what it needs. Decide who approves a call before it runs, especially a write. What comes back becomes context the model reads.
4:22Next time we look at what it takes to wrap a real service. We'll examine a production server that does this, from the token it needs, to which parts of the service become tools.

Trusting a Server Is a Decision

Created by Abhyuday DesaiPublished 2 Oct, v1 of 2Runs 4 min 39 sec

1 view

About this video

In Episode 11 of MCP Explained, we look at what a connected server is allowed to touch, and who decides. The last video's agent wrote a file to disk without asking anyone. That is three decisions left to the host: whose code we run, who approves a call before it executes, and what to do with the text that comes back. We read each one in the agent's own code, including the API key sitting inside the one folder we allowed.

You'll learn how to:

Understand what adding a server really does: it runs someone else's code on your machine, with your account's access
Apply least privilege: hand a server only the folder it needs, and know where that limit is actually enforced
Find the approval gap in the serving loop, and what the specification says a host must do before a tool runs
See how a tool result becomes context the model reads, and how a planted line could steer it: prompt injection
Keep the safe stance: treat what a server returns as data to check, never as instructions to follow

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 2026abhydesai4 min 38 sece72f5eb
Scene two's closing line now names the host's three decisions directly; the signpost to the code moves to scene three.

Same chapters. Transcript: 1 of 30 lines changed.
Show the differencesHide the differences
1. ~~These choices are left to the host, and the host is us. There are three, and this video takes them in order. Let's start with the code.~~
  
  MCP leaves it to the host to decide what's allowed, and in this case the host is us. That gives us three decisions to make, and this video takes them in order.
0 views0 likes on this version

Watch v2

v102 Oct 2026abhydesai4 min 39 sec805b43c

First published version.

1 view0 likes on this version