Choose Your Wire
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 Chapter 56, Lesson 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.
Ask the Skill
Open Claude Code in the project you set up in Lesson 2 and ask:
Explain the MCP transport options. I want to build an MCP server
for a learning platform. What are my options and which one should
I use? Explain the tradeoffs simply.
Read the response. The skill walks you through the options with tradeoffs specific to your use case.
Make the Decision
Now you choose. The skill gave you the tradeoffs. Ask yourself three questions:
- Should your server work only on your laptop, or from anywhere? One option locks you to the same machine. The others work over the network.
- Should your server track who is calling between requests? Session tracking adds complexity: storage, cleanup, crashes that lose sessions. The alternative is simpler: each request carries everything the server needs.
- Who remembers the conversation? Your agent already tracks context through the gateway. Does the MCP server need to remember too, or can it handle one tool call at a time?
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.
Update CLAUDE.md
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:
- Use streamable-http stateless transport on port 8000
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.
Try With AI
Exercise 1: Explain Stateless to Your Team
Copy this prompt into Claude Code or your preferred AI assistant:
I chose streamable-http stateless for my MCP server. Explain to
me like I'm presenting to my team: why stateless over stateful?
Give me three concrete advantages.
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.
Exercise 2: When stdio Wins
When would stdio transport be the better choice than
streamable-http? Give me two scenarios where local-only
makes more sense.
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.
Exercise 3: Your Domain, Your Decision
I'm building an MCP server for [describe your domain here].
Should I use stateful or stateless transport? Walk me through
the decision.
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."