Tool use and MCP

What you’ll learn

How tool calling works under the hood, what the Model Context Protocol is and why it caught on, and how to give an agent tools without giving it the keys to everything.

How tool calling works

Tool use, sometimes called function calling, follows a simple exchange. You tell the model what tools exist, each with a name, a description, and the arguments it takes. When the model decides to use one, it does not run it. Instead it emits a structured request naming the tool and its arguments. Your code, or the framework, actually runs the tool and hands the result back to the model, which reads it and decides what to do next.

Two things follow from this. First, the model is only as reliable as its ability to produce that structured request correctly, which is why tool-tuned models make better agents. Second, nothing happens unless your code runs it, so the boundary of what an agent can do is entirely in your hands.

The Model Context Protocol

Early tool use was bespoke: every framework wired up tools its own way, and a tool built for one did not work with another. The Model Context Protocol, or MCP, emerged as a shared standard for connecting models to tools and data sources, and it has been widely adopted across the ecosystem.

The value of a standard is reuse. An MCP server exposes a capability, access to a filesystem, a database, a search API, a set of developer tools, in a common way, and any MCP-aware client can use it. Tools like Cline speak MCP, and a growing library of servers means you can give an agent a new capability by pointing it at a server rather than writing an integration. Because MCP servers can run locally, this fits a local-first setup well: the tools, like the model, stay on your machine.

Keeping tool access safe

Tools are where an agent stops being a text generator and starts affecting the world, so this is the part to treat with care.

• Grant the least access needed. Give an agent the narrowest tools for the task. An agent that only needs to read files should not have write or shell access.
• Prefer read-only and reversible tools where you can, and require confirmation for anything destructive.
• Sandbox powerful tools. Filesystem and command execution are best run in a container or a disposable environment, so a misfire is contained.
• Watch the loop. Log what tools an agent calls and with what arguments, so you can see what it did and stop it if it goes wrong.

What can go wrong

• Over-broad tools. A single tool that can run any shell command is convenient and dangerous. Narrow, specific tools are safer and often work better.
• Trusting tool output blindly. An agent will act on whatever a tool returns, including errors or malicious content. Treat tool results as untrusted input.
• Format failures. A weaker model may call a tool with malformed arguments, breaking the loop. Tool-tuned models and clear tool descriptions help.

Next steps

With tools understood, agent frameworks and local models covers the software that ties the loop and the tools together, and how to run it all against a local model.