A large language model is, at its core, a function that maps text to text. Ask it what the temperature is right now in Bengaluru, what today's date is, or whether a specific flight still has seats, and it cannot know any of those things—not because it is poorly trained, but because none of them are facts. They are the current state of the world, and the model has no channel to the world at all. It has no clock, no network socket, no database connection, and its training data stops at a fixed cutoff date, after which nothing has reached it. Every one of its 'facts' is a static compression of text it saw during training, not a live observation.
Tool use is the mechanism that closes this gap. Rather than asking the model to guess, hallucinate, or refuse, you give it a catalogue of capabilities it is allowed to invoke: look up the weather, query a database, read a file, call an internal API. The model does not gain hands, a clock, or a network connection by being given tools—what changes is that it can now say, in a structured and checkable way, exactly what it wants done, and your code decides whether to do it. This lesson is about that boundary: what a model can never do on its own, and the precise shape of the request it hands off to you instead.
This distinction is not a technicality. It is the entire safety and reliability model of every tool-enabled system you will build in this course. Every guardrail you add, every permission you check, every retry you write lives in the space between the model asking and your code acting. Get comfortable with that boundary now, because the rest of the course—defining tools well, running the execution loop, and standardizing it all with MCP—is built entirely on top of it.