A Model with Tools

Until now the model has been a conversationalist: it knows things, it reasons, and it can do precisely nothing. It can't look anything up, can't check, can't open your file, can't run the calculation it just described.

Tools change that, and the change isn't one of degree. But the mechanism is far simpler than the marketing suggests, and understanding it correctly is what lets you predict where it will break.

What a tool call actually is

The model still only reads and writes text. That never changes.

What's new is that some of the text it writes is addressed to a program outside it. It emits, in effect, "search the web for X" or "run this code" or "read this file" — a structured request rather than prose. The surrounding program intercepts that, actually performs the action, and places the result back on the desk as more text. The model then continues, now with the result in front of it.

The model still only writes text. Some of that text now gets executed.

That loop — request, execute, result on the desk, continue — is the entirety of it. Web search, code execution, file reading, connected systems, and the agents in the next article are all the same loop with different things on the other end and different numbers of repetitions.

Why it changes the picture anyway

Three consequences, and each one moves something you learned earlier.

Facts can come from outside. The knowledge cutoff stops being a wall, and fabrication drops sharply, because the answer is built from a retrieved page rather than from the landscape. This is the single biggest reliability improvement available.

Computation becomes verifiable. Instead of generating a number in prose, it writes code, the code runs, and the number comes from execution. Article 8's advice — ask for a method you can run — stops being manual.

Actions have consequences. Reading is safe. Writing, sending, paying, deleting and publishing are not, and the moment a tool can do those, every mistake in this sphere acquires a price beyond a bad answer.

The main kinds

Search — for anything time-sensitive or beyond the cutoff.

Code execution — arithmetic, data processing, file conversion, charts. The model writes it, a sandbox runs it, both of you see the output.

Your files — a document you attach is read into the context, or processed by code. Two practical notes: a scanned PDF with no text layer contains no text as far as the model is concerned until it's recognised, and large spreadsheets are far better handled by code than by reading.

Connected systems — your drive, your repository, your task tracker, your calendar. This is where MCP comes in: an open protocol Anthropic published in late 2024 so that a tool and a model don't need a bespoke integration for every pair. It's a standard socket, not a capability of its own — worth knowing the name because it's how most connections are described now.

Computer use — the model driving a screen: clicking, typing, navigating. Newest, slowest and least reliable of the set; useful when there's no API, and it deserves a sandbox rather than your actual desktop.

What changes about verification

Grounding cuts one class of error and introduces another.

Fabrication falls. Misreading doesn't — the page was real, the interpretation was wrong, and now the wrong interpretation is a "sourced fact" that everything downstream is built on. A confident chain of reasoning on top of one misread sentence is harder to catch than a plain invention, because it comes with a citation.

Which gives you a new and very effective checking point: look at the calls, not just the answer. What did it search for? Which pages did it actually open? What did the code it ran contain, and what did that code output? Most tool-enabled failures are visible right there — a query that missed the point, a file it never opened, a script that silently dropped half the rows. Reading the call log takes fifteen seconds and catches things the prose will never reveal.

Security stops being theoretical

Article 11 introduced prompt injection as a structural property: the model can't reliably separate data from instructions, because both are text on the desk. With tools, that stops being an interesting fact.

A model that only reads a poisoned page produces a bad answer. A model that reads a poisoned page and can send email, edit files or call your systems can be instructed by that page. The danger scales with permissions, not with content.

Four principles, and they're the same ones any sensible system uses:

• Least privilege. Read-only unless writing is genuinely needed. Narrow scopes over broad ones.
• Separate sensitive access from untrusted content. The risky configuration is one session that both holds your credentials and browses arbitrary pages.
• Confirmation on the irreversible. Sending, paying, deleting, publishing — your finger, every time.
• Watch what it calls. Unexpected tool calls are the visible symptom of an injection.

In practice

Turn search on for anything recent — and open the links that matter.

Prefer executed code to stated numbers whenever a figure will be used.

Read the call log, not just the conclusion. Wrong query, unopened file, silent data loss.

Give files in a form that's actually readable — text layer present, big tables handled by code.

Grant the narrowest permissions that do the job, and keep irreversible actions behind your own confirmation.

Check yourself

Close the article and answer in your own words:

1. What literally happens during a tool call, and what stays exactly the same about the model?
2. Which three things change once tools exist, and which earlier article does each one revise?
3. What is MCP, and why is it not a capability in itself?
4. Which class of error does grounding reduce and which does it introduce or worsen?
5. Why is the call log a better checking point than the final answer?
6. Why does injection risk depend on permissions rather than on what the model reads?

In short

• A tool call is text the model writes that a program outside executes, with the result placed back on the desk. The model still only reads and writes text.
• Everything — search, code, files, connectors, agents — is that same loop with different endpoints and different repetition counts.
• Tools bring facts from outside (fixing the cutoff and much fabrication), make computation verifiable, and introduce actions with consequences.
• MCP (Anthropic, 2024) is an open standard socket for connecting tools to models, not an ability of its own.
• Grounding cuts invention but not misreading — and a misread source is harder to catch because it arrives with a citation.
• Check the calls, not just the answer: wrong query, unopened file, script that dropped rows.
• Injection risk scales with permissions: least privilege, separate sensitive access from untrusted content, confirm the irreversible, watch the calls.
• The model still only writes text. Some of that text now gets executed.