The default way most people work with an AI model is a chat box. You paste in some text, it responds with more text, and you copy that text somewhere and act on it yourself. That works, but it caps what the model can do at "produce words." The moment you give the model tools it can call, the ceiling moves. It stops guessing about your data and starts working with the real thing, and it can take actions instead of handing you a to-do list.
This is the difference between describing your database to the model and giving it a tool that queries the database. One is a game of telephone. The other is the model reading the actual rows.
What a tool actually is
A tool is two things. First, a description the model can read: a name, a plain-language explanation of what the function does, and a typed list of parameters. Second, the infrastructure on your side that actually runs the function when the model asks for it and returns the result back into the conversation.
The mechanism is a loop. The model, mid-response, emits a structured request that says "call query_contacts with state = CA." Your runtime intercepts that, runs the real function, and feeds the return value back in as another message. The model reads the result and continues. From the model's side it looks like it "knows" your contacts. It doesn't. It asked, and something ran, and it got an answer.
That framing matters because it tells you where the work is. The model handles deciding which tool and what arguments. You handle everything else: authentication, running the query, catching errors, and shaping the return value into something the model can use. A tool call is a collaboration between the model's judgment and your code's execution.
Why tools beat pasting
When you paste data into a chat window, three things go wrong over time.
The data goes stale the instant you paste it. You copied yesterday's numbers. The model reasons confidently about yesterday's numbers. A tool that queries live pulls today's, every time, with no human in the copy-paste loop.
You're the bottleneck for every action. The model can write the email, but you send it. It can describe the file change, but you make it. Every action routes through you re-typing or re-executing what the model already worked out. A tool lets the model send the email, write the file, or run the command itself. You approve the shape of what it can do once, in the tool definition, instead of babysitting each individual action.
The model guesses at structure it can't see. Describe a database schema in prose and the model will infer column names, get some wrong, and write queries against fields that don't exist. Give it a tool that returns real rows and the guessing stops. It works from ground truth.
I lean on this constantly in my own setup. My agents don't get told what emails arrived; they call a tool that returns the actual message metadata since a cutoff date. They don't get a description of a contact note; they read the file. The fleet of agents I run in production is entirely built on this. Take away the tools and every one of them collapses back into a chat box that can only produce suggestions.
Descriptions are the interface
Here's the part people underestimate. The tool description isn't documentation. It's the interface the model programs against. The model never sees your implementation. It sees the name, the description, and the parameter list, and it makes its entire decision to call or not call from that text.
Get the description wrong and the failure is quiet. The model picks the wrong tool, or passes a plausible-but-wrong argument, or skips a tool it should have used, and you get a confident answer built on the wrong action. A few things that hold up:
- Say what the tool does and when to use it, in plain language. "Retrieves email metadata (subject, sender, date) received after a given epoch timestamp. Use before deciding whether to fetch full message bodies." That last sentence steers selection as much as the first.
- Name parameters like a human would.
contactEmailandsinceDateEpochcommunicate intent.p1andarg2make the model guess, and it guesses wrong on the parameters with non-obvious constraints exactly when it matters most. - State side effects out loud. A tool that sends an email should say so in its description. Models are appropriately cautious about actions with consequences, and they use that signal. A read tool and a write tool that look identical in their descriptions are a bug waiting to happen.
If you want to test a description, don't wire it into anything yet. Open a chat, describe the tool and a situation, and ask the model whether it would call it and with what arguments. If its reasoning doesn't match yours, the description needs work before you depend on it.
When to build a tool instead of pasting
Not everything needs a tool. Building one is real work: you write the function, handle auth, shape errors, and maintain it. Three signals tell you it's worth it.
- Recurring need. If you paste the same kind of data more than a few times, that's a tool. One-off analysis of a spreadsheet you'll never touch again is a paste.
- Live data. If the answer depends on the current state of a database, an inbox, or an API, a tool keeps the model honest. A static snapshot from last week doesn't.
- Actions with side effects. If the useful outcome is something happening in the world (an email sent, a row written, a file moved, a command run), that only exists as a tool. Text describing the action isn't the action.
If none of those apply, paste and move on. Tools are infrastructure, and infrastructure you build for a single use is waste.
Scope tools narrowly
The instinct is to build one powerful tool with a dozen parameters and a mode flag. Resist it. A model choosing between a few narrow, well-named tools makes better decisions than a model configuring one Swiss-army tool through a pile of optional arguments.
Narrow tools have fewer wrong ways to call them. archiveContact and deleteContact as two tools are safer than modifyContact(action) where the model has to pick the right string for a destructive path. Every parameter you remove is a decision the model can no longer get wrong.
There's a second reason. Each agent should only receive the tools it needs for its job, not your entire catalog. Handing a model a smaller, sharper set of tools keeps its context focused and cuts the odds of a wrong selection. My CRM sync agent gets email and vault tools; it never sees the calendar or image-generation tools, because it has no business touching them. Narrow tools, narrowly granted.
MCP: a standard way to expose a catalog
Once you have more than a handful of tools, you need a way to expose them that isn't bolted into each client. That's what the Model Context Protocol solves. MCP is an open standard for publishing a catalog of tools that any compliant model or client can connect to and use. You define the tools once on a server; Claude Code, a desktop client, or your own agents all connect to the same catalog.
My own runs as a single Spring Boot deployment: 59 tools across 12 functional domains, everything from Obsidian vault operations and email retrieval to S3, CalDAV, and outbound notifications. Both my scheduled agents and my interactive sessions talk to that one server. When I add a tool, every client gets it at once, with no per-client wiring. I wrote up how that server is built in a separate piece on its architecture, including why one server beats many and how the tool descriptions are tuned.
The catalog grows unevenly, which is worth knowing going in. One of my domains carries 26 tools; most carry one or two. That's fine. The point of MCP isn't a tidy count. It's that the model has a stable, discoverable menu of real capabilities, and adding to that menu doesn't mean touching every place the model runs.
The shift
The move from chat box to tools is the move from a model that talks about your work to a model that does your work. Pasting keeps the model at arm's length from reality: it reasons about your description of the data, and you execute everything it suggests. Tools close both gaps at once. The model reads the real state, and it takes the real action.
Start with one tool for the thing you paste most often. Watch how differently the model behaves when it's holding the actual data instead of your summary of it. That first tool is usually enough to change how you think about the whole relationship.