A language model produces text. On its own it cannot look anything up, run a calculation, query a database or send a message. Tool use is the mechanism that closes that gap, and it is the single most consequential addition to these systems since instruction tuning.
How tool use actually works
The common misconception is that the model calls the tool. It does not, and the distinction matters for security.
You send the model a list of available tools, each with a name, a description and a schema for its parameters. The model, instead of replying with prose, emits a structured request: this tool, these arguments. Your code then decides whether to execute it, does so, and returns the result as another message. The model sees the result and continues.
So the model only ever asks. Every actual action passes through code you control — which is where permission checks, confirmation prompts and audit logging belong. Any system that executes model-requested actions without that layer has made a choice, not an oversight.
Two current refinements
Parallel calls. Models now commonly request several independent tools in one turn, and the harness may execute them concurrently. The requirement is that all results return together, matched to their request IDs. This is a large latency win for independent lookups. Tools that act on shared state — browser or computer control especially — must still run sequentially.
Structured outputs by constrained decoding. Earlier systems asked nicely for JSON and validated afterwards. Current implementations compile your schema into a grammar and permit only schema-valid tokens during generation, making invalid output structurally impossible rather than merely unlikely. This converts a reliability problem into a non-problem, with caveats: refusals and truncation still break the guarantee, and there are limits on how many strict schemas one request can carry.
The problem MCP solved
Tool use works well for a handful of tools you wrote yourself. It scales badly across an ecosystem. Every application needed bespoke integrations for every data source, and every integration had to be rebuilt for each AI client. The result was an N-by-M mess.
The Model Context Protocol is the open standard that addressed this. A tool provider implements an MCP server once; any MCP-compatible client can use it. One integration, many clients.
Adoption has been fast and the governance is now genuinely neutral — MCP was contributed to a Linux Foundation body with platinum backing from most of the major cloud and AI providers, including several direct competitors, and published server counts run into the thousands. For a protocol introduced recently, that is an unusual trajectory; the closest analogy is the language-server protocol in developer tooling.
The specification has not been static. The 2026 revision was a substantial redesign toward a stateless request-response core, deprecating session-based transports, adding cacheable tool listings and hardening authorisation — changes aimed squarely at running MCP through enterprise gateways at scale rather than on a developer’s laptop. Features such as long-running tasks and managed enterprise authorisation were moved out of the core into formal extensions.
MCP is not the only protocol
A common confusion is treating MCP and Agent2Agent as competitors. They address different layers. MCP connects an agent to tools and data. A2A connects agents to other agents, including across organisational boundaries, with its own concerns around identity and signed capability descriptions. Both have since landed under the same foundation, which rather settles the rivalry framing.
When you have too many tools
Ecosystem success created a new problem. Connect several MCP servers and you may present a model with hundreds of tool definitions — consuming a large share of the context window before the task begins, and degrading accuracy as the model selects among near-duplicates.
Current mitigations, with measured effects reported by vendors:
- Deferred loading and tool search. Rather than listing everything, let the model search for tools when needed. Reported context reduction of roughly eighty-five per cent, with substantial accuracy gains on large tool sets.
- Programmatic tool calling. Let the model write code that orchestrates several tools in a sandbox, returning only the conclusion. Intermediate output never enters the context window — a material saving when tools return large payloads.
- Tool use examples. Include worked examples of correctly-formed calls alongside schemas.
Treat those figures as vendor-reported. The direction is well supported; the magnitudes are not independently replicated.
The security caveat that governs everything
Every tool result re-enters the model’s context as ordinary tokens, indistinguishable from instructions. A document, web page or API response containing text aimed at the model is an attempted injection, and there is no reliable mechanism separating data from instruction in the token stream.
This is why the architectural point at the top matters so much. The boundary that protects you is not the model’s judgement. It is the code between the request and the action. See AI agents explained for how this shapes agent design.
Last reviewed: September 2026. Protocol specifications are actively revised; verify against current documentation.
