Your Agent Needs Hands
James had his agent running. WhatsApp connected. Skills installed. Schedules configured. He had spent the last ten lessons building something real, and it worked. He could message it at 3am and get a coherent answer. He could ask it to summarize a document and it would pull from its memory. The dashboard showed green across the board.
Then a student in his test group asked a simple question: "Can your agent check whether I completed yesterday's lesson?"
James stared at the message. His agent knew everything about the course curriculum. It could explain any topic, generate quizzes, suggest study plans. But check a database? Verify a specific student's progress record? It had no way to do that. He typed a response himself and closed the laptop.
"It knows everything about the course," he told Emma the next morning. "It can explain any lesson, break down any concept. But when a student asks 'did I finish lesson 3,' it just... guesses. Or apologizes."
Emma set down her coffee. "You already know what is missing. You fixed this once before."
You are doing exactly what James is doing. You have a working AI Employee from Chapter 56. It chats, remembers, follows schedules, and uses skills. Now you are hitting the wall: your agent knows about your domain, but it cannot act on it.
No code in this lesson. The goal is the mental model. Code starts in Lesson 2.
Knowledge Has a Ceiling
James thought about it. "At my old shipping company, we hired a logistics consultant once. Brilliant guy. Could explain every routing algorithm, every customs regulation, every port efficiency metric. But when I asked him to check whether container TEMU-4421 had cleared customs, he had to call someone. He had the knowledge. He did not have access."
"Your agent is that consultant right now."
"It knows about timezones." James thought back to the time server he had configured in Lesson 7. "Before I added it, the agent answered from training data. UTC+9, JST, all correct. After, it checked a live clock. Same question, different source." He paused. "Actually, not always the same answer. Daylight saving transitions, leap seconds, server drift. The training data gives the rule. The live clock gives the fact."
Emma nodded. "That is the line. Training data gives knowledge: what timezones exist, how offsets work, when daylight saving starts in theory. A tool gives ability: what the actual time is, right now, on a live system. Your agent can talk about databases all day. Without a tool, it cannot run a single query."
James started listing things his agent could not do. "It cannot check student progress. It cannot verify assignment submissions. It cannot look up a learner's name in any system. It cannot send an email notification. It cannot ping an API to see if a service is healthy." He was counting on his fingers. "It is a consultant who never leaves the conference room."
Training data gives an agent knowledge: what timezones exist, how databases work, when daylight saving starts in theory. A tool gives an agent ability: what the actual time is right now, whether a specific student completed lesson 3, whether a service is healthy. No amount of training data replaces a live connection.
You Already Crossed This Line Once
"You already solved this problem once," Emma said. "In Lesson 7."
James remembered. He had added the mcp-server-time server to his agent's configuration. One JSON file, one restart, and suddenly his agent could check live clocks across every timezone. The tools appeared in the dashboard. The agent started using them without being told.
"But I didn't build that server. I just connected to it."
"Exactly. You were a consumer. Somebody else built the time server, packaged it, published it. You plugged it in." Emma drew two circles on a napkin. "Consumer: you take an existing server and configure your agent to use it. Producer: you create a new server that exposes tools your agent does not have yet."
"Same protocol both ways?"
"Same protocol. MCP does not care which side you sit on. The wire looks identical. What changes is your responsibility. As a consumer, your job was configuration: get the JSON right, restart the gateway, verify the tools loaded. As a producer, your job is design: decide what tools to expose, what inputs they accept, what your agent can do with them."
James looked at his napkin. "So the time server was someone else's hands. Now I need to build my own."
Consumer: you take an existing MCP server (like mcp-server-time) and configure your agent to use it. Your job is configuration. Producer: you create a new MCP server that exposes tools your agent does not have yet. Your job is design. Same protocol, different responsibility.
You Do Not Write the Server Yourself
"Before you panic," Emma said, "you are not going to hand-write a server from scratch."
James looked relieved. "Because I remember Part 4. We drove the entire TDG cycle through Claude Code. I wrote specs, Claude Code wrote code, I verified."
"Same pattern. But this time you have a specialized skill for MCP servers." Emma pulled up her laptop. "It is called mcp-builder. You install it into Claude Code, and it gives Claude Code deep knowledge about how MCP servers should be structured, what patterns work, what pitfalls to avoid. Without the skill, Claude Code can still write an MCP server, the same way it can write any code. With the skill, it writes one that follows proven patterns and handles edge cases you would not think to ask about."
"Like the difference between asking a general contractor to wire a house versus asking a licensed electrician."
"Good analogy. The general contractor can probably do it. The electrician knows the code." Emma smiled at the double meaning. "You describe what you need. Claude Code, with the skill loaded, builds it. You verify. Same loop as Part 4."
James stared at his list of things his agent could not do. Five minutes ago it felt like a wall. Now it felt like a list of tools to build.
Five steps: (1) install a skill that gives Claude Code domain expertise, (2) configure CLAUDE.md with project rules, (3) describe what you need in plain language, (4) Claude Code builds the implementation, (5) you verify the result. You own the requirements. The agent owns the code.
Emma looked at his list. "Honestly, I am not sure how many of those will work as single tools versus needing to be split up. We will figure that out when we get to the specs."
"Next lesson: set up the workshop. Install the skill, create the project, configure Claude Code. Then we choose how the server talks to agents, and then we build."
Try With AI
You do not have the mcp-builder skill installed yet. That is Lesson 2. Use these prompts in ChatGPT, Claude, Gemini, or your preferred AI assistant.
Exercise 1: Knowledge vs Ability
What is the difference between an AI agent that knows about databases
and one that can query a database? Give me three concrete examples
where an agent's training data lets it discuss a topic intelligently
but cannot replace a live tool connection. For each example, describe
what the agent can do with knowledge alone and what changes when it
gets a tool.
What you are learning: The boundary between knowledge and ability is the central concept of this chapter. Training data lets an agent discuss timezones, databases, APIs, and weather patterns. Tools let it check the actual time, run a real query, call a live endpoint, and fetch a current forecast. Recognizing this boundary helps you decide when your agent needs a new tool versus better prompting.
Exercise 2: Tools for Your Domain
I want to build an MCP server for [describe your domain: tutoring,
e-commerce, healthcare scheduling, inventory management, etc.].
What tools would my agent need to go from "knows about my domain"
to "can act on my domain"? List 5 tools, each with a name, a
one-sentence description, and the specific action it performs that
training data alone cannot.
What you are learning: Designing tools starts with identifying the gaps between what your agent knows and what it needs to do. This exercise forces you to think about your own domain before the chapter introduces the formal tool design process. The tools you list here will inform your choices in Lesson 4 when you spec and build your first real tool.
Exercise 3: Producer vs Consumer
In Chapter 56, I configured a time server (mcp-server-time) so my
AI agent could check live clocks. I was a consumer: someone else
built the server, I plugged it in.
Now I want to build my own MCP server so my agent can check student
progress in a learning platform.
Explain the producer vs consumer perspective in MCP. What stays the
same between consuming an existing server and producing a new one?
What changes? What new responsibilities do I take on as a producer
that I did not have as a consumer?
What you are learning: The protocol is the same on both sides. What changes is your responsibility. As a consumer, you configure and verify. As a producer, you design, build, and maintain. Understanding this shift prepares you for the rest of the chapter, where every lesson adds producer responsibilities that did not exist when you were just plugging in someone else's server.