Tools other agents can trust, in brief
Lesson 3 made a model’s answers honest with schemas. Lesson 4 faces the other direction: the tools an agent calls, and the craft of building them so an agent can use them the way you meant. The track spine runs through the middle of it. A tool’s interface is where one agent’s judgment meets another system’s guarantees, and this lesson is about writing the guarantee side well.
The capability: after this lesson, you can design a small toolset an agent selects from reliably, write error responses the agent can actually recover from, and build and configure an MCP server of your own without a credential ever landing in version control.
What the lesson covers. The load-bearing fact is that a model chooses tools by reading names, descriptions, and schemas, never source code, so the description is the selection mechanism. A reliable description states purpose, inputs, outputs, boundaries, and when to use the tool versus its named siblings. From there the lesson splits an overloaded do-everything tool into purpose-specific contracts, names tools so they cannot be confused, and builds an error taxonomy: transient failures where retrying helps, business-rule refusals where it never will, permission problems, and the costly difference between a failed query and a successful query that found nothing.
The second half turns builder. Least-privilege distribution gives each agent only its role’s tools, since oversized toolsets degrade selection and widen risk. Then the lesson builds the server side of MCP, the counterpart to the consumer-side lesson in Building with Claude: tools versus resources, docstrings as descriptions, and Claude Code’s configuration scopes, where project scope shares a server through version control and environment-variable expansion keeps the API keys out of it.
Why this order. Descriptions come before servers because the hard part of a tool is not the code. It is the text the model reads when deciding whether to trust it.