Build a server — writing a tool.
Less scary than it sounds: a function, a description, and one line to run it.
To make a tool available over MCP you write a small server. It is not a big production: at its heart it is one ordinary function, plus a description so the model knows what the function is for, plus a line that runs the whole thing.
We will build one that answers the exact question that made the VAR hallucinate back in Lesson 6 — “how many times has this striker been flagged offside this season?” Instead of guessing, the VAR will call a match-stats 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.