James had his agent running. WhatsApp connected. Skills installed. Schedules configured. He had spent the last ten chapters 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 chapter?"
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 chapter, break down any concept. But when a student asks 'did I finish Module 1, Chapter 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 Module 9.1. 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 chapter. The goal is the mental model. Code starts in Module 9.2, Chapter 2.
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 Module 1, Chapter 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."
The Concept: Knowledge vs Ability
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 Module 1, Chapter 3, whether a service is healthy. No amount of training data replaces a live connection.
"You already solved this problem once," Emma said. "In Module 1, Chapter 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."
The Concept: Producer vs Consumer
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.
"Before you panic," Emma said, "you are not going to hand-write a server from scratch."
James looked relieved. "Because I remember Module 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 Module 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.
The Concept: Skill-Driven Build Pattern
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 chapter: 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."
You do not have the mcp-builder skill installed yet. That is Module 9.2, Chapter 2. Use these prompts in ChatGPT, Claude, Gemini, or your preferred AI assistant.
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.
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 Module 9.2, Chapter 4 when you spec and build your first real tool.
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 chapter adds producer responsibilities that did not exist when you were just plugging in someone else's server.