The Tool-Call Loop

You know the headline fact: an LLM cannot execute anything — it only generates text. This lesson drills the full mechanical loop that turns that text-generator into an agent, because "walk me through what happens when the model calls a tool" is a question that rewards narrating mechanics the way you'd narrate an HTTP request/response cycle. Four steps, every time.

The four steps

1. Tools are declared to the model up front. Each tool the model may use is described in the context as a schema: a name, a description, and typed parameters — for example get_weather(city: string) — returns current conditions. The model can only "see" tools whose schemas it was handed. (This declaration step is exactly what MCP discovery feeds: the client asks the server what tools exist and passes their schemas to the model.)

2. The model emits a structured request — nothing more. When the model "decides" to use a tool, what it actually does is generate structured output instead of prose: { "tool": "get_weather", "arguments": { "city": "Sacramento" } }. Say the demystifying sentence out loud in interviews: a tool call is still just next-token prediction — the model is generating text shaped like a request. It has done nothing yet. It cannot do anything.

3. The runtime executes with its permissions, not the model's wishes. The agent runtime (your code, or a framework) validates the request against the schema and actually performs the action — calls the API, queries the database, reads the file. Every security property lives here: least-privilege credentials, read-only access where write isn't needed, allow-lists, and human confirmation gates for consequential actions. The model has exactly the powers the runtime grants — a well-designed runtime is why "the AI went rogue" isn't a thing that can happen in your architecture.

4. The result returns to the context, and the loop continues. The tool's output is appended to the conversation as a new message, and the model generates again — now conditioned on the result. It either answers the user or emits the next tool call. An "agent" is exactly this loop running: model proposes, runtime executes, result returns, repeat until done. That one sentence is the whole demystification of agents.

MCP: the standard for step 1 and step 3

Before the Model Context Protocol, every AI application integrated every tool with custom glue — M apps × N tools meant M×N bespoke integrations. MCP standardizes the plumbing: a server exposes tools (their schemas, discovery, and invocation) over a standard protocol, and any MCP-capable client can use them. Build the server once; every current and future client plugs in.

The interview-ready framing for your own work: "It's like USB for AI tools. I built an MCP server exposing our 106-field credential record layout — field lookup, line parsing, file validation — and any MCP client can use it without custom integration. And because the runtime holds the permissions, I made the database access read-only at the server level: whatever any model ever asks for, writes are structurally impossible." That last clause turns a description into an architecture decision — which is the level the panel is hiring.

The security tie-in (say it before they ask)

Step 4 has a sharp edge: tool results are untrusted content re-entering the context. A web page fetched by a tool, a document retrieved from a share, an email read by an assistant — any of them can contain instruction-shaped text, and the model will read it in the same window as its real instructions. This is indirect prompt injection, and it's why the defenses live in the runtime layer: least-privilege tools, confirmation gates on consequential actions, and treating everything a tool returns as data. Volunteering this unprompted — "and the loop is also the attack surface, which is why…" — is a senior move.

Interview drill

Narrate the loop cold, in order, with the two punchlines: (1) declare schemas → (2) model emits a structured request ("still just next-token prediction") → (3) runtime executes with its permissions ("security lives here") → (4) result re-enters context, loop continues ("an agent IS this loop"). Then the MCP paragraph with your read-only server as the example. Ninety seconds, no hesitations — it's the question you're most likely to get asked given the MCP line on your resume.