Skip to content
MCP Five

Start Here4 / 51

The arc

Each project broke the previous one's assumption. That is the spine of the course.

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.

D1 Β· the arc
Five projects, and the question each transition answers. Read the labels on the arrows: every one of them is a question the previous project did not know it had assumed an answer to.

The assumption that broke, five times

  1. πŸͺ 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.

  2. πŸ” 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_file tool. "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.

  3. βœ‹ 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.

  4. πŸ‘₯ 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 sampling capability turns up, and a server can ask your host to run a model call. On your key. Your MAX_TREE_TOKENS now guards everything except the one spender you don't control.

    β†’ so project #5 put the server's draws on the same tab.

  5. πŸ’Έ 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 while loop 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.00 is 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.