Build a server — writing a tool.
Less scary than it sounds: a function, a description, and one line to run it.
To offer a tool over MCP you write a small server. There is not much to it: one ordinary function, a description telling the model what that function is for, and a single line that runs the whole thing.
We will build one that answers the exact question that made the umpire hallucinate back in Lesson 6 — “how many times has this batter been caught behind this series?” Instead of guessing, the umpire will call a scorecard server that looks up the real number.
The one idea to hold onto: the tool's description — its name, its typed inputs, and its docstring — is what the model reads to decide when and how to call it. You are writing two things at once: code for the computer, and instructions for the model.
Add the server one piece at a time, and watch the tool definition the model receives take shape alongside the code.
A tool is a function you describe well.
An MCP server is a small program that holds one or more tools. Each tool is a plain function, marked with @mcp.tool(), whose name, typed inputs and docstring are turned into a description the model can read. Write that description like instructions, run the server, and you have a tool.
The code does the real work the model can't; the description is how the model knows the tool exists and how to use it. Both matter — a perfect function with a vague docstring is a tool the model never calls right.