TL;DR
Hand-wiring tools (Module 2) means translating every API into a model-facing tool definition, by hand, and keeping it in sync forever. The Model Context Protocol (MCP) flips that: the server describes its own tools, and the agent discovers them at connect time. You trade total visibility for reach and zero maintenance.
The problem with hand-wiring
In Module 2 you gave the agent a lookup_account tool: a name, a description, a
JSON-schema for the parameters, and a handler. Fine for one tool. But a real support
agent needs to look up orders, list a customer's history, issue refunds, file
tickets, check tickets — and that's one service. Add a payments provider, a
shipping API, and a CRM, and you're hand-writing and maintaining dozens of tool
definitions that all have to stay in sync with APIs you don't control.
Every one of those definitions is the same shape you already know:
Notice what you're really doing: translating an existing API into the model-facing tool shape, by hand, over and over — and re-checking it every time the API changes.
Analogy
Hand-wiring is like manually re-typing a restaurant's menu into your own app for every restaurant in town, then re-typing it again whenever they change a price. MCP is the restaurant publishing its own menu in a standard format — you just read it.
What MCP changes
MCP is a standard way for a server to describe its own tools. Instead of you writing the definitions, the server hands them to the agent: "here are my tools, their names, descriptions, and parameter schemas." The agent discovers them at connect time. The payoff:
- Discovery, not authoring. One connect call returns every tool. Add a tool on the server and the agent sees it next run — no code change on your side.
- One client, many servers. The same MCP client talks to any MCP server, the way one browser talks to any website.
- Definitions stay with the service. The team that owns the API owns its tool descriptions, so they can't drift out of sync with your copy.
So it isn't "HTTP or MCP?" — a service can have both. MCP sits in front of (or beside) the API and answers one question the raw API never did: what tools do you offer, and how should a model call them?
The trade you're making
Hand-wiring gives you total control and total visibility — you can see every request in your own source. MCP gives you reach and zero maintenance, but the wiring is hidden behind the protocol.
| Hand-wired HTTP | MCP | |
|---|---|---|
| Tool definitions | You write & maintain them | Server publishes them |
| New tool on the service | You add code | Agent discovers it next connect |
| Visibility | Every request is in your source | Requests happen behind the protocol |
| Reach | One integration at a time | Any MCP server, one client |
Most of the time MCP is the right trade. In this module's lab you'll connect the same Help Desk both ways and watch the difference land in real traces — choosing with your eyes open, not on faith.
Common mistake
Thinking MCP gives the model new abilities. It doesn't — the tools are the same functions either way. MCP changes how tool definitions reach the agent (discovery vs. authoring), not what the model can do once it has them.
Key takeaways
Key takeaways
- Hand-wiring tools doesn't scale: every API becomes a definition you maintain by hand.
- MCP lets a server publish its own tools; the agent discovers them at connect.
- One MCP client talks to any MCP server; new tools appear without code changes.
- The trade: reach and zero maintenance vs. the visibility of hand-wired requests.
Go deeper: MCP also standardizes more than tools
Tools are the headline, but MCP servers can expose three kinds of capability:
- Tools — functions the model can call (the focus of this module).
- Resources — read-only data the host can pull in as context (files, records, documents), addressed by URI.
- Prompts — reusable, server-defined prompt templates a user can invoke.
The unifying idea is the same as for tools: instead of every app re-implementing integrations, a server describes its capabilities once in a standard format, and any MCP-speaking client can use them. That's why MCP is often described as "a USB-C port for AI applications" — one connector, many peripherals. This module stays on tools because that's what your lab agent needs, but the discovery mechanism is identical for all three.