Here’s something that stays strange to me no matter how many times I sit with it: for all their brilliance, these models can only produce text. That’s the entire native ability. A model, by itself, cannot log into anything, cannot send a message, cannot spend a single rupee. It’s a remarkable mind in a sealed jar — it can think about the world in astonishing detail and touch none of it.

And then you hand it a tool, and the jar opens.

What a tool actually is

“Tool” here isn’t marketing fluff — it’s a precise technical term, the one MCP made standard. A tool is a function the model is allowed to call: a labeled action, with defined inputs, wired to real code that does something in the real world. That’s it. You are giving the model a remote control, and each button on it is a tool.

Here is one button, spelled out:

tool  get_keyword_ideas
  does     → calls the Google Ads Keyword Planner API
  inputs   → { seed_keywords, location, language }
  returns  → [ { keyword, monthly_searches, avg_cpc, competition }, … ]
  safety   → readOnlyHint   (it can only read — it can't spend a rupee)

The mechanism from there is almost anticlimactic in how simple it is. The model reads your ordinary English sentence, decides which button (or buttons) to press and with what inputs, presses them, gets structured data back — not prose, real fields it can compute on — and turns that back into an answer for you in plain English.

How a tool call flows Your English ask goes to the model; the model presses a tool button; the tool runs against a real system and returns structured data; the model turns that back into a plain-English answer. HOW A TOOL CALL ACTUALLY FLOWS your ask, in English the model decides · explains the tool runs acts on a real system the answer, in English presses a button structured data back
The model still only produces text — it just gets to say “press this button with these inputs.” The button runs your real code, hands back structured data, and the model turns it into an answer.

Notice that the model never stopped being a text machine. It didn’t grow arms. All it gained was permission to say, in a form your code understands, press this button with these inputs — and on the other side of that button is anything you were willing to wire up. The intelligence decides; your code acts; the intelligence explains. That loop is the whole trick, and I introduced its skeleton a few essays ago as “a model in a loop with tools.” This is what the tools half was hiding.

The little word that keeps it safe

Look again at that last line of the spec: readOnlyHint. Every button can carry a label describing what it’s capable of — this one only reads; it can look up keyword data but it physically cannot move money. Other buttons would be marked differently: one that sends an email acts, one that charges a card spends and can’t be taken back.

This is the same discipline I keep coming back to — a capability is only trustworthy when something guards the irreversible edge of it. But here it arrives as good news, not a warning: because the danger is labeled, you can hand over the safe powers wholesale and reserve your attention for the few buttons that actually matter.

The part that lifts the ceiling

Now the exciting bit, the reason I wanted to write this at all.

Once you can define one tool, you can define any capability your code can express. There is nothing special about keyword data. Query your own database. Fetch a live web page. Send a message. Book a slot. Move money, if you dare and you guard it. Deploy a site. Each is just another labeled button, and the model will press exactly the right ones for the sentence you gave it.

The model's control panel of tools A text-only model wired to five labeled tool buttons — read-only tools that query data and the web, and acting tools that send mail or spend money — each carrying a safety label. EACH TOOL IS A LABELED BUTTON, WIRED TO SOMETHING REAL the model text in · text out powerless alone — until you wire buttons get_keyword_ideas → Google Ads API read query_database → your own data read fetch_page → the live web read send_email → someone’s inbox acts charge_card → real money spends Read tools run freely. Tools that act or spend are guarded — you decide when they’re allowed to fire.
Define one button and you can define any capability your code can express — your data, the web, a mailbox, a payment. The model brings the judgment about which to press; the safety label decides what it’s allowed to touch.

A model alone is a mind in a jar. A tool is the first hand it reaches through the glass — and you get to decide how many hands, and what each one may touch.

— the thing I keep grinning about

Wire up a handful and something larger appears: the model stops answering questions and starts running work. Give it a read tool, a decide step, an act tool, and a way to check the result, and it will research, choose, do, and verify — a whole workflow, driven by one English request. This is why the protocol underneath matters so much. When the buttons are described in a standard way, any model can press any tool, and tools become composable — you snap capabilities together like bricks instead of rebuilding the wiring every time.

Why this is such a good time to build

I’ve spent most of my recent writing on the hard, humbling parts — how context decays, how a skill is only a wish, how “done” has to be earned. All true. But I don’t want the caution to hide the thing underneath it, which is close to joy.

The distance between I have an idea and a thing that acts in the world used to be an entire engineering project. Now it is roughly: how fast can you describe the goal and wire a few buttons? You are no longer building the whole machine by hand. You are handing a genuinely capable mind a small panel of labeled controls and pointing it at something you care about. The mind was the hard part, and it arrived. The buttons are the easy part, and they’re yours to design.

That is a wildly good position to be in. A solo builder can now assemble, in an afternoon, what used to need a team and a quarter — not because the work got trivial, but because the largest, slowest piece is finally handled, and what’s left is the part that was always the most human: deciding what should exist, wiring the right capabilities to reach it, and keeping a careful hand on the buttons that can’t be undone.

A mind in a jar was a marvel to talk to. A mind with hands — buttons labeled, seatbelts on, pointed at a real goal — is a collaborator. I’ve been building software for more than fifteen years, and I have never been more excited to make things than I am right now.

It is a very good time to build. Reach a hand through the glass and start.