The host that
owns the wallet
Five projects into a series named after the protocol, every server has been a vending machine: request in, result out, costing you nothing beyond the request.
Sampling turns that inside out. The server asks your host to run a model call. It has no API key and no model — it has yours.
This is the sharper version: that boundary can now spend your money.
MCP has five capabilities. We had used one.
Projects #1 to #4 used tools and nothing else. Three of the remaining four are the same shape as the one you know — you ask, the server answers. The fourth reverses the arrow.
The contractor with your account number
Every supplier so far has been a vending machine in the hallway. You put coins in, you get flour. Sampling is a contractor who can phone your supplier and charge it to your account. They may be doing excellent work — the money leaving the account is still yours, and the decision to spend it was theirs.
host ──tools/call──▶ server host ◀───result───── server you pay for YOUR model calls only
host ──tools/call──────────▶ server
host ◀──"input_required: server
run this model
call for me"
▼ your key. your bill.
model
host ──tools/call + answer──▶ server
host ◀───result────────────── server⚠️ It is a retry, not a callback — and that surprised us
Every tutorial describes sampling as the server pushing a request down the open connection. That is the 2025 protocol, and it cannot work on a serverless host — there is no connection to push down. The 2026-07-28 revision removed the server→client channel entirely and replaced it with a retry: the server says input_required, your host does the work, and your host calls the tool again with the answer attached. We found that by probing a live server, not by remembering it.
Watch it happen
Ask for a pantry digest. The kitchen server reads the event log itself — then asks your host to write the summary, because it has no model of its own. Ask for a deep one and it wants a bigger model and every jar's full report, which is about thirty times the price.
Pick one, or ask your own.
Start with the first one. It splits the pantry across sub-agents, gets short reports back, and then asks you once, with a list, before emptying anything.
Which server cost you money, and why
Project #4's meter could tell you a run cost 83,000 tokens. It could not tell you that some of them were spent by somebody else. Turn a ceiling down to two cents and ask for the deep digest — your own host will tell your own server no, and the refusal costs nothing, because it happens before the model is ever contacted.
Eight seatbelts, three of them new
Every limit projects #2–#4 built is still here. A server that can ask for model calls is a new kind of spender — and it is not yours — so it gets three of its own.
Per agent. One agent spinning is a bill, not a hang.
A rate limit on sub-agents. The model may ask for more; they queue.
A quantity limit. Concurrency without a total is sixty workers, three at a time.
One wallet for the whole tree. A server's model call now draws from this same pot — which is the only reason the number still means what it says.
Sub-agents never receive spawn_agent. An absence, not a counter that could be off by one.
A spend ceiling, per server, on the ESTIMATED cost of a model call it asked for. Cheap calls flow; expensive ones stop before a token is spent.
A server may request any maxTokens it likes. It gets this or less.
A per-call ceiling with no total is a machine for making a thousand cheap calls.
Rewind any run
Every event is written to Postgres as it happens — which bought something bigger than a replay UI. A stored trace contains everything an eval's check() reads, so the regression suite re-scores 60-jar sweeps for $0.00. Run the model once; score it fifty times.