Clyepv204 Oct 2026abhydesai5 min 3 sec915046c
Re-recorded from the current scenes. Version 1 was a take from before the 29 September and 1 October edits, so it showed an older cut: the opening headline read "A server worth keeping", scenes 3 and 6 were the earlier versions, the trace scene was missing and the narration was longer. This version matches the series as written.
Chapters: one added. Transcript: 36 of 47 lines changed. 60 sec longer.
Show the differencesHide the differences
- Chapter added
- The trace
-
So we give it two more ways to look things up. That is most of this video.So we give it two more ways to look things up.
That is most of this video.
-
And last, a ready-made prompt, written for whoever wants to use this server.This is the same server file, with the two new tools already written in. Let's take the one we already had first.The first one returns a single number, and nothing else.And last, a ready-made prompt, written for whoever wants to use this server. Let's start with the tools.
This is the server file, with the two new tools already written in. The one we already had is still at the top.
It returns the latest price.
-
The first gives back a closing price for each of the last few days, which is what a question about a whole week needs.It takes a second argument, and that one has a default. The caller can say how far back to go, or leave it alone.So it is five days unless the caller asks for more. The second tool is further down the file.This one returns the closing price for the last few days, and the second argument specifies how far back we go.
The second tool is further down the file.
-
Both are plain lookups. Each hands its argument to yfinance and turns the answer into text, the same as the first.Both are plain lookups. They pass the ticker to yfinance and return the answer as text.
-
Think for a second about what answering that takes. You would need this week's prices, and then the news to explain them, and the question names neither one.All three tools were offered for this one question.It asked for the week of prices, then for the news.It read the three descriptions and picked the two that fit.Here's our question to the model. We are asking how Nvidia's stock moved over the past week, and what explains it. Think for a second about what answering that takes.
You would need this week's prices, and then the news to explain them. And the question names neither one.
All three tools were offered for this question.
It read the three descriptions and picked the two that fit: the week of prices, then the news.
-
By design, a resource is read by the app, not called by the model. So this is the side that has to ask for it.Our app reads it when you name a company on the command line. Then it puts those three facts in front of the model with your question.That choice belongs to our app, not to the model.So let's name one.The company is chosen by you, before the model sees anything.And the answer comes back from those three facts.That line is our app reading the address we filled in.There is no tool call in that run, because nothing here was the model's to decide.One thing left in the server, and that is the prompt.Let's scroll down to it.By design, a resource is read by the app, not called by the model. Let's see that in a run.
We name Apple with the about flag, and ask whether it is a hardware or a services company.
That flag in front of the question is what makes the app read the profile before the model sees anything. We will trace exactly how in a minute.
The app read the profile, and the model answered from it.
That line is the app reading the profile.
There is no tool call in that run.
Recall that we used the about flag in front of the question. Now let's trace the whole request through the app.
This is our app, and the request starts in main.
There are six steps from the flag to the answer.
We arrive in main. It has already connected to the server, and now it hands the command line to ask_for.
ask_for checks the first argument. Ours is the about flag, so it takes this branch, with a ticker and a question.
It builds the address from the ticker, reads the profile from the server, and returns it with the question after it.
Back in main. What comes back is the profile and the question together.
It goes to the model as the user message, the same as a plain question would.
The model has what it needs in the message, so it answers without asking for a tool, and the app prints the answer.
That is the path of an about question, from the flag to the answer. One thing is left in the server, and that is the prompt.
It is at the bottom of the server file. Let's scroll down to it.
-
That knowledge usually stays in the author's head. Here it ships with the server. -
You never write the question yourself.Your one word became that question, and the question needs all three tools.We name the morning briefing prompt with the prompt flag, and give it Nvidia's ticker.
That flag makes the app ask the server for the question and fill in the ticker. Nothing we typed is a question.
The prompt name expanded into that question, and answering it takes all three tools. The connection and the tool list come first, as always, and then the model starts on the lookups.
-
Three kinds of things, and they are not used evenly. In practice, nearly everything you will meet is tools.That was the last of the three additions this video promised: two more tools, a resource, and a prompt. In practice, tools are most of what a server offers, and most of what you will build.
-
The part in the middle never changed. Our app connects and asks what is there. Next time we watch that exchange.The connection itself never changed. Our app connects and asks the server what it has. Next time we look at that exchange, message by message.