Unit 7 of 9 · Intermediate

How an agent reaches out of the chat box

In one read

A language model, on its own, can only produce text — it cannot check a price, send an email, or place an order. So it is given tools: named functions it is allowed to request. This is function calling, and the loop is simple. The model decides it needs something and asks to call a tool by name, with arguments. The tool runs in real software — your systems, a vendor's API — and the result is handed back. The model reads that result and continues, calling more tools until the task is done. This is the mechanism behind every agent that does something rather than merely says something: the model supplies the judgment, the tools supply the reach. Two things follow. A tool is exactly as capable and as bounded as whoever wrote it, and an agent can only ever do what its tools permit — no more, no less.

A model alone can only talk

A language model, by itself, produces text and nothing else. It cannot check a live price, read your database, send an email, or place an order. Left alone, it is the chatbot from unit one — articulate, and unable to touch the world.

The bridge out of the chat box is a tool: a named function the model is allowed to request. Giving a model tools, and letting it call them, is function calling.

The loop, step by step

Function calling is a short, repeating exchange:

  1. The model decides it needs something it cannot do itself — say, the current value of a position.
  2. It asks to call a tool by name, with arguments: getPosition(id: "…").
  3. The tool runs in real software — your systems, a vendor's API, a database — and produces a result.
  4. The result is handed back to the model, which reads it and continues, calling more tools until the goal is met.

That is the entire mechanism behind every agent that does rather than says. The division of labor is clean: the model supplies the judgment, the tools supply the reach.

Two consequences worth holding

  • A tool is exactly as trustworthy and as bounded as whoever wrote it. A tool that can only read cannot write; a tool with a spending cap cannot exceed it. The tool's own limits are the agent's limits.
  • An agent can only do what its tools allow. Add a tool and you widen what it can do; withhold one and that action is simply not available to it. This is where the "which tools is it allowed to touch" question from the last unit becomes concrete.

The catch that the next unit solves: wiring each tool to each agent by hand is slow and repetitive. That is the problem MCP was built for.

See it in kestrel

Kestrel gives an agent a small set of bounded market tools — run a session, read the result, act — each one grantable and revocable. Watch it on a generic instrument, no signup, no card:

npx kestrel.markets sim fomc-rate-decision-whipsaw

It prints a certified proof URL you can recompute yourself. Drop the kestrel.markets MCP server into your client and the tools are available again next session — no account in between.

Recompute it

Every claim in this unit recomputes from a certified proof — no account, no card.

/proof/art_d29415f0cf502f4a218a9cba
Keep readingWhat MCP is (for finance)

Agent twin: /education/agents-fundamentals/af-tools-and-function-calling/content.md