James had his project folder ready. The mcp-builder skill was installed. CLAUDE.md described the project. He opened Claude Code and almost typed "Build me a tool that checks learner progress."
Then he stopped.
"Wait." He looked at his notes from Module 9.1 and Module 1, Chapter 7. Three transports: stdio, SSE, streamable-http. Back then, the table was just reference information. Now he had to pick one. "If I start building without deciding how the server talks to agents, I will end up rebuilding the wiring later."
Emma glanced over. "You have the skill for this."
"The skill." James turned back to his terminal. "Not Google. Not the docs. The skill I installed yesterday."
You are doing exactly what James is doing. Before building, you choose how your server talks to agents.
Open Claude Code in the project you set up in Module 9.2, Chapter 2 and ask:
Read the response. The skill walks you through the options with tradeoffs specific to your use case.
Now you choose. The skill gave you the tradeoffs. Ask yourself three questions:
If your answers are "from anywhere," "no session tracking," and "agent remembers," you land on streamable HTTP, stateless. That is what James picked. That is what we use for the rest of this chapter.
You made a decision. Now record it so Claude Code follows it in every future session. Open your CLAUDE.md and add the transport rule:
Add this to the existing rules list. Your CLAUDE.md now has four rules: use the skill, use uv, spec first, and use stateless HTTP on port 8000. Every time Claude Code builds or modifies the server, it reads these rules and follows them.
Copy this prompt into Claude Code or your preferred AI assistant:
What you are learning: Articulating an architectural decision is a skill. The choice is only valuable if you can explain it to someone who was not part of the conversation.
What you are learning: Every transport has a context where it is the best option. Stateless HTTP is right for TutorClaw, but knowing when stdio wins sharpens your ability to evaluate tradeoffs in future projects.
Replace the bracketed text with your own project. If you do not have one in mind, use "a personal finance tracker that checks account balances."
What you are learning: The decision framework transfers to any domain. The transport choice depends on your specific requirements, not on a universal rule.
James leaned back and read through his conversation with the skill. "I just made an architecture decision without writing a line of code. Just a conversation."
"That is the pattern." Emma closed her laptop halfway. "Decide first, build second. You would not pour a foundation before choosing the building material."
"Stateless." James nodded. "It is like shipping labels. Every label has the complete destination address. The warehouse does not need to remember which dock you used last time. Each package is self-contained."
Emma laughed. "That is actually a good one. I wish I had thought of it that way two years ago. I built an MCP server for a client's inventory system and chose stateful because 'sessions sounded professional.' Six weeks later I was debugging session cleanup timers at 2 AM. Sessions that expired mid-request. Sessions that leaked memory because the cleanup cron job ran on the wrong timezone." She shook her head. "Stateless would have been half the code and none of those bugs."
"So stateless is always better?"
"No. Stateful exists for a reason. Some servers genuinely need to track a multi-step workflow across requests. But for a tool server where each request is 'check this learner's progress' or 'fetch this quiz,' stateless is the obvious fit." She opened her laptop again. "You picked the right wire and recorded it in CLAUDE.md. Every time Claude Code works on this project, it reads that file and uses stateless HTTP. Now describe your first tool."