James had been thinking about what he needed since the previous chapter. He opened a notebook (the paper kind) and wrote three words: register a learner.
"That is the first thing TutorClaw has to do," he said. "Before tracking progress, before assigning lessons, before anything. A learner walks in, we record their name, we give them an ID."
Emma leaned over and read the notebook. "Good. You know what you want. Describe it to Claude Code. What you need, not how to build it." She stood up. "I have a call. When I get back, show me the spec."
James watched her leave. He stared at his terminal. Three words in his notebook. How do you tell an AI what you need without telling it how to build it?
You are doing exactly what James is doing. You describe what you need, Claude Code builds it, Claude Code verifies it works.
In this chapter, you walk through the full cycle: describe a tool, review the spec Claude Code produces, steer the design if needed, and let it build and test. The mcp-builder skill you installed in Module 9.2, Chapter 2 guides Claude Code through best practices so you can focus on what the tool should do.
Open Claude Code in your tutorclaw-mcp project (the one you set up in Module 9.2, Chapter 2). Send this message:
Notice what this message contains and what it leaves out. It contains:
It does not contain any Python, any file paths, any framework choices. Those are implementation decisions. Claude Code and the mcp-builder skill handle them. The transport and port are already configured in CLAUDE.md from Module 9.2, Chapter 3 — you do not need to repeat them.
Claude Code responds with a spec before writing any code. The spec typically includes:
Read the spec carefully. The most important element is not the parameter types or the return format. It is the tool description.
When an agent has access to multiple tools, it reads each tool's description to decide which one to call. The description is a job posting. A vague posting attracts the wrong candidates. A specific posting attracts exactly the right one.
Compare these two descriptions for the same tool:
If Claude Code's spec has a vague description, that is your first steering point.
The spec is a proposal, not a contract. You review it and push back on anything that does not match your requirements. Common steering moves:
Sharpen the description:
Add parameters:
Adjust the output:
You might approve the spec on the first pass. You might steer three times. Both are normal. The point is that you see the plan before any code exists.
Once the spec looks right, tell Claude Code to implement it:
Claude Code does the rest. It creates the project, writes the server code, writes tests, and then verifies everything works:
You do not run any commands yourself. Claude Code handles the full build-and-verify cycle. When it finishes, it tells you whether everything passed and asks if you want it to start the server so you can explore with MCP Inspector.
What is MCP Inspector?
MCP Inspector is a visual tool that lets you call your server's tools one at a time and see the inputs and outputs. It is a good way to poke at your server before connecting it to your agent. If Claude Code offers to start the server for you, say yes, then in a second terminal run npx @modelcontextprotocol/inspector and connect to the URL Claude Code shows you.
Step back and notice the pattern. You did not write a server. You did not learn framework syntax. You did not configure anything. You:
Claude Code handled the implementation. The mcp-builder skill ensured best practices. This is the same spec-driven development pattern from Module 3 applied to MCP server creation: you own the requirements, the agent owns the code.
The hardest part was not building. It was knowing what to ask for. Getting the tool description right, choosing the right parameters, deciding what the output should look like. Those are design decisions that require understanding your domain. Claude Code cannot make them for you.
Review the tool description Claude Code wrote for register_learner:
What you are learning: The tool description is the single most important line in your server. A good description makes the agent reliable. A bad one makes it guess.
You need a second tool for TutorClaw: tracking a learner's progress. Describe it to Claude Code, but ask for the spec only:
Compare the spec to the one for register_learner. Are the descriptions specific enough that an agent would never confuse the two?
What you are learning: When you have multiple tools, the descriptions must be distinct. Overlapping descriptions force the agent to guess which tool to call.
Ask Claude Code what the mcp-builder skill added:
What you are learning: Skills encode expertise. The mcp-builder skill carries patterns from well-tested MCP servers. Building without it works, but you miss the patterns you do not know you need until something breaks in production.
When Emma came back from her call, James had the results on screen. Tests passed, server booted, tool call returned a welcome message.
"All I did was describe what I wanted and push back on the description twice," James said.
"How many times did you rewrite the description before you sent it?"
"Three." James grinned. "Same thing used to happen with purchase orders at the warehouse. First draft was always too vague. You learn what details matter by getting it wrong once."
"That is the hard half. Knowing what to ask for." Emma looked at the spec. "Honestly, I still second-guess my own tool descriptions. Describing when an agent should pick one tool over another is harder than writing the server code." She shrugged. "That part is yours. You know the domain."
James looked at the results. "So it works. But nobody else is sending it requests."
"Module 9.2, Chapter 5. Connect it to your agent on OpenClaw and test from WhatsApp."