0:01 An AI model can't press a single button. Not on a calculator, not on a website. All it can ever do is write text. That's why the advice is: don't ask a model to be a calculator. Give it one. Yet agents built on these models fix code, dig through sales figures, and click through websites. What makes that work is a few lines of description, and some code you write.
0:31 Get those lines wrong, and the agent grabs the wrong tool, or guesses. When Anthropic built an agent to fix real code, its team spent more time on the tools than on the whole prompt. So how does a model that can only write text do anything at all?
0:58 What a tool is
Here's the plan. What a tool is. How a model uses one. What makes a good one. Then MCP, the standard way to plug tools in. So what is a tool, to a model? It's two things. Some code, and a description of it. The code is the easy half: an ordinary function that works out the sum exactly. The description is the half the model sees.
1:27 Picture it as one item on a menu. It has three parts. A name: calculate. A line or two on what it does, and when to use it. And the inputs it takes. Here, just one: the sum. Together, they're called a tool definition. The inputs part is the input schema, written in a format called JSON Schema that spells out what each input must look like. So where does the model see it?
1:58 Every request goes to the model as a form: instructions at the top, then you, then an empty part for the answer. The tool definition goes in the instructions, the system prompt. In Google's open model, Gemma, our calculator adds 95 tokens there. OpenAI's docs say the same: the tools go into the system prompt. So to the model, a tool is just words in its instructions.
2:27 It never sees your code. Only what you wrote about it.
2:35 How does the model use one?
So how does the model use one? Ask it: what's 487 times 356? The model reads the form, one trip through its dials, and out comes the wheel: a slice for every token it could write next, sized by its score. Gemma's list has a few special tokens just for tools, and one of them opens a request. Here, that one might get a big slice. If the spin lands on it, the model has started asking for a tool.
3:07 Picking a tool is just another guess. And like any guess, it can be wrong. Then it writes the request, one token per trip. Call calculate, with the sum: 4 8 7, times, 3 5 6. 19 tokens, from the one that opens it to the one that closes it. This request is the tool call, also called a function call. And once it's written, the app stops the model.
3:36 The model only asks. Your code acts. Your code reads the request, and decides what to do with it. Check it, run it, or refuse. If a model asks to delete a file, nothing is deleted unless your code deletes it. Here, your code works it out: 173,372. That answer is written into the form, right after the request.
4:06 It's called the tool result. Then the model reads the form again, result and all. This time it writes an answer, with the right number in it. That's one tool call, start to finish. Each request and each result stays in the form, for every trip after. And it ends when the model writes an answer, instead of a request. A sum needs one tool. A real agent often needs several at once, like one asked why sales dropped last month.
4:39 To compare EMEA with the month before, it can ask for both months at once: two requests, back to back. Your code runs them side by side, and sends both results back together. One wait instead of two. These are called parallel tool calls. They only work when neither request needs the other's answer. And when a tool fails, that's a result too. Say the agent asks for sales.csv, but someone has renamed it.
5:13 If your code just crashes, the run stops there. If it sends back, error, the model has to guess. So send back an error that helps: what went wrong, and what to try next. No file called sales.csv. This folder has Q4 sales, and targets. On its next trip, the model reads that, and asks for Q4 sales.
5:43 If the description is all the model goes on, what makes a good one?
So if the description is all the model goes on, what makes a good one? Anthropic's docs call it by far the most important factor in how well a tool works. Write it for a new colleague, who's never seen your systems. That's Anthropic's advice. OpenAI's version is the intern test: could an intern use it, with only what you gave the model? Take the sales agent's database tool. A bad description says: runs a query. 4 tokens.
6:15 Now the model must guess the tables, the column names, and the currency. A good one runs to four sentences, about the least Anthropic suggests. What the table holds. That amounts are in US dollars. That it returns 100 rows at most. And when to use another tool instead. 69 tokens, and nothing left to guess. Sometimes the best fix isn't more words.
6:43 Anthropic's coding agent kept getting file paths wrong, once it had moved out of its starting folder. So the team changed the tool to always need the full path. After that, the model used it flawlessly. Pick a few good tools, not one for every call in your API. A tool that hands back every order makes the model read thousands of rows for one number. One that answers, EMEA's total last month, hands back one line.
7:14 And don't hand it too many. In one of Anthropic's examples, five popular services bring 58 tools, and about 55,000 tokens, before anyone has typed a word. The commonest mistakes are the wrong tool, or the wrong inputs, especially when two tools have similar names. So give each tool one clear job, and a name nothing else shares. Google and OpenAI say about 20 tools.
7:44 Past that, let the model search for them. So a tool description isn't documentation. It's a prompt. And it's all the model will ever know about your tool.
8:00 So far, you've written every tool yourself
So far, you've written every tool yourself. But what if your agent needs GitHub, Slack, Google Drive and your database, and your team uses three different AI apps? Until late 2024, that meant wiring each app to each service by hand. 3 apps, 4 services: 12 connections to build, and keep working. In November 2024, Anthropic published an open standard for this.
8:30 Its own docs compare it to a USB-C port: one plug shape for everything. It's called the Model Context Protocol, or MCP. Each service is wrapped once, as an MCP server. Each app learns MCP once, as an MCP client. 3 + 4: 7 pieces, not 12. A server is just a program that offers tools. The app asks it: what tools do you have?
9:01 And back comes a list: names, descriptions and input schemas. The same three parts as our calculator. The app writes them into the form. When the model asks for one, the app passes the request to the server, which runs it and sends back the result. So nothing changes for the model. It still reads descriptions, and writes requests. MCP only changes who wrote the tool, and where its code runs.
9:31 A server can also offer resources, like files to read in, and prompts, ready-made instructions. And it caught on. OpenAI added it to its toolkit for building agents in March 2025. By the end of that year, ChatGPT, Gemini, Microsoft Copilot and VS. Code supported it, and Anthropic had handed MCP to a new Linux Foundation group, set up with OpenAI and Block.
10:00 By September 2026, its software kits neared half a billion downloads a month. And everything about good tools still applies. Those 58 tools in Anthropic's example? They came from five MCP servers. And remember: a server is code someone else wrote, running with whatever access you give it. What can go wrong there gets an episode of its own.
10:30 How does a model that can only write text do anything at all?
So how does a model that can only write text do anything at all? It doesn't. It writes a request, from a menu you described. Your code decides whether to run it, runs it, and hands back the result. The model only asks. Your code acts. So write every description like a prompt, for a new colleague. Next: what a model can see.
