The first week of July. The chapter has changed. The past six months dealt in possibility; this half deals in the order you build things. Two pieces went up in week one.
This week's Signal
Back to the floor. "A First MCP Server" is the first rung of this chapter. A few dozen lines serving four notes as tools, and one line of path registered in Claude Desktop's config. That is all of it — no store, no deployment, no review. Type "save that to my notes" in a chat and code on my laptop executes. A dart test raises the server as a separate process and checks the round trip and persistence by itself.
And 45 lines stand next to it. "Forty-Five Lines" is a tool somebody made on a weekend afternoon after running a neighbourhood club's dues out of a chat thread and a notes app. This time we counted lines rather than hours — how many for the screen definition, how many for the server. Hours differ by person; line counts do not.
Tool and package notes
In mcp_server's stdio mode, stdout is a channel reserved for JSON-RPC. Let one diagnostic line out through print and it breaks the protocol stream. That is why every error output in this server goes only to stderr. A good share of "why does parsing fail sometimes" in embedded work comes from the same place.
A short thought
After raising a first server, most people reach the same wrong conclusion — now I have to go learn the protocol. The opposite. The initialize handshake, tools/list and stdio framing are all hidden by the package. What is left is writing what a tool means. Writing that sentence well matters more than the code, because it is what the model uses to choose the tool.
Next week
We move to receiving the screen from the server and drawing it. Then a piece on stopping "who may press this button" at the tool boundary.
makemind.dev "Signal" — once a week, what went up and what got in the way while building it.