Code Execution as the Universal Tool — Tool Use, Function Calling & MCP

Every tool this course has built so far is narrow on purpose: `read_invoice` reads one invoice, `check_status` checks one status, `send_email` sends one email. Each one exists because someone sat down, enumerated a specific operation the model would need, and wrote a handler and a schema for exactly that operation. That works well right up until the operation the model actually needs is one nobody enumerated in advance — filter these two thousand rows by a condition nobody wrote a tool for, convert this column of mixed units, join the output of one tool against the output of another in a way no single handler was built to do. A narrow-tool catalogue answers questions it was designed to answer; it has no answer at all for the question it wasn't.

Code execution is the tool that removes the enumeration problem entirely. Instead of calling a handler you wrote for one specific operation, the model writes the operation itself — real code, in a real interpreter, running inside a sandbox — and the sandbox executes whatever the model composed. One tool, `execute_code` in spirit if not always in name, now covers the entire space of operations expressible in a general-purpose language, which is a strictly larger space than any finite set of narrow tools could ever cover, no matter how many you write.

That power is not free. A narrow tool's input_schema is a contract: an `input_schema` that requires an `invoice_id` string can only ever be called with an invoice ID, and your dispatcher can check that mechanically before the handler runs. A code-execution tool's schema is, structurally, just "a string of code" — there is no schema shape that distinguishes a legitimate data transformation from a malicious one, because both are syntactically valid code. This lesson works through where that trade genuinely pays off, where a narrow tool still wins outright, and the sandbox discipline — state, dependencies, resource limits, and the security posture from lesson 23 — that makes handing a model a real interpreter survivable in production.

Analogy🏏Cricket

🏏 Think of it like cricket: A modern franchise nets facility can be built two different ways. One way lines up a rack of a dozen fixed-setting bowling machines — a machine hard-wired to fire nothing but yorkers, another that only sends down bouncers at a set pace, another dialled permanently to a leg-spinner's googly — and a batter who wants a slightly different combination, say a fast, full ball angling into the pads from around the wicket, simply doesn't have a machine for that; someone has to buy or build a new one. The other way installs a single adjustable machine that a coach can dial to any speed, line, length, seam angle, and release height on the fly — the kind of setup Virat Kohli has used for years in the M. Chinnaswamy Stadium nets to rehearse deliveries no single fixed machine was ever built to reproduce. The adjustable machine is strictly more capable — it can compose a combination nobody enumerated in advance — but the trade is real: a fixed machine can only ever do the one thing it was built for, so nobody needs to check whether today's setting is sensible, while the adjustable machine will just as faithfully fire whatever combination the dial is set to, sensible or not, and someone still has to get the dial right. That is the whole trade between a code-execution tool and a rack of narrow ones: composability in exchange for a machine that trusts the dial.