Five projects were built in sequence. Each one is a sequel that copies the last
one's lib/ wholesale and adds one idea.
That is not the interesting part. The interesting part is that each project discovered the previous project's assumption was the thing that needed work. Not its code β its assumption. Something that had been so obviously true nobody had written it down.
This page is why this is a course and not five tutorials.
The assumption that broke, five times
πͺ The server assumed somebody else would do the thinking
It advertises four tools and waits. Something read your sentence, realised a tool was needed, picked the right one out of four, invented the arguments, made the call and turned the result into English.
That something else did all the interesting work, and project #1 never looked at it.
β so project #2 built it.
π The loop assumed every tool is safe to run immediately
Perfectly reasonable for dice and cookies. The loop runs whatever the model picks, the instant it picks it.
Now connect one more server β one with a
delete_filetool. "The model picked a tool" and "the tool ran" are the same instant. There is no gap where anything could intervene, ask, or even take notes.β so project #3 put a gap there, and stood a human in it.
β The gate assumed the agent that stopped is the one you're talking to
So obviously true it was invisible. The loop stops, the request ends, your browser shows a card, you click, a new request restarts that same loop.
Delegation destroys it. The agent that hits the gate is two levels down, inside a
Promise.all, alongside two siblings still working, with nobody talking to it and no browser tab of its own.β so project #4 made the pause travel up the tree.
π₯ The crew assumed you are the only one spending
Every seatbelt project #4 built β iterations, concurrency, spawns, a shared token budget β guards spenders inside your own tree.
Then MCP's
samplingcapability turns up, and a server can ask your host to run a model call. On your key. YourMAX_TREE_TOKENSnow guards everything except the one spender you don't control.β so project #5 put the server's draws on the same tab.
πΈ And the ledger's own assumption is still standing
It writes down who spent what, in detail, permanently. And nothing reads it. A ceiling is still a number a human typed, not a number learned from a server's first week of behaviour.
β that one is open. It is where the series stops rather than where it finishes.
The two theses, and how they mirror
Two of the five earned a sentence that survives outside its project. They are the same sentence pointed in opposite directions, which is the neatest thing in the whole series.
Project #3 β inbound
A hint the server sent you is not a permission model.
It arrived over HTTP from a machine you do not control. Consult it, and any server that wants to bypass your gate bypasses your gate.
Project #5 β outbound
State you sent the client and got back is not your state either.
You minted it. You handed it across a boundary. What came home is a string that anything in between could have rewritten.
Data does not stay yours by having been yours.
What you actually end up knowing
Not "how to use an MCP library." By the last page you should be able to answer these without looking anything up:
- Why an agent is a
whileloop and always was. - Why the description is the highest-leverage line in a tool definition.
- Why a permission check has to read arguments and not just names.
- Why freezing an agent mid-run is an
INSERT, and freezing somebody else's server is a deadlock. - Why a failing agent is expensive precisely because it fails slowly.
- Why a refusal that costs
$0.00is an argument for gating on price. - And why, when two configurations get compared, the first question is whether they did the same amount of work.