Lesson 5: Tools and Function Calling

A note on this series. This is written for beginners, on purpose. I’m keeping explanations at a practical, conceptual level rather than a technical one. Several ideas here are described in generic terms rather than their full technical depth. The goal of these seven lessons is to demystify AI agents enough that the hype becomes understandable and ideally to spark enough curiosity that you go looking for the deeper technical material afterward.

Lesson 3 named tools as the agent’s hands. This lesson opens up how that actually works under the hood, because the mechanism of function calling is one of the key pieces of engineering that lets language models move from generating text to operating software through external tools.

The basic mechanism

A model can’t literally reach out and click a button or run code. What it can do is output text in a very specific, structured format that says “call this function, with these parameters.” The software running around the model watches for that structured output, recognizes it as a tool request, executes the function (a real API call, a database query, a web search), and feeds the result back to the model as new text for it to keep reasoning over.

So the model never runs anything itself. It requests. The surrounding system, sometimes called the agent harness or runtime, does the actual running and reports back. This separation matters for safety: whoever builds the harness decides what tools exist, what they’re allowed to touch, and whether a human needs to approve a given call before it happens.

Every major model provider supports some version of this now. OpenAI’s function calling, Anthropic’s tool use, and Google’s equivalent in Gemini all work on the same basic principle, even though the technical details differ slightly between them.

The integration problem, and why MCP exists

A practical headache showed up as agents multiplied: every tool a model might want to use, your calendar, a code repository, a spreadsheet, a company database, needed its own custom-built connection. Multiply dozens of tools by multiple AI products and you get a tangle of one-off integrations that’s expensive to build and painful to maintain.

Anthropic introduced the Model Context Protocol, or MCP, in November 2024 as an open standard meant to solve exactly that problem: one consistent protocol for AI applications to connect with compatible tools and data sources, instead of requiring a completely different integration pattern for every pairing (Generative Inc, 2026). The shorthand that’s caught on in the industry: MCP is something like a USB-C standard for AI, a shared connector so tools and models can plug into each other without bespoke adapters every time (Kapini, Medium, 2026).

Adoption has moved fast. Other major AI companies, including OpenAI and Google, added support for MCP within months. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. Anthropic, Block, and OpenAI co-founded the foundation, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. By then, Anthropic said more than 10,000 active public MCP servers were in use across the ecosystem (Generative Inc, 2026). Thousands of MCP-compatible tool servers now exist for things like GitHub, Slack, databases, and file systems. Developers, and increasingly non-developers, can connect an agent to real services without writing custom integration code for each one.

MCP handles model-to-tool connections. A separate protocol, Agent-to-Agent (A2A), addresses a different problem: how independent agents, possibly built by different companies on different frameworks, talk to each other and hand off work. As multi-agent systems become more common, covered in Lesson 6. As multi-agent systems become more common, agent-to-agent communication is emerging as a separate interoperability problem alongside tool and data integration.

What goes wrong once a model can act

This is also where the stakes change. A chatbot that gets confused just says something wrong. An agent with tools that gets confused can send the wrong email, delete the wrong file, or run a command it shouldn’t have. A model that acts is a model that can cause real, sometimes irreversible, damage.

The risk to know here is prompt injection: text the agent reads, a webpage, a document, an email, that contains instructions disguised as content. If the agent can’t tell the difference between “the user asked me to do this” and “a sentence buried in a file is telling me to do this” it may follow the injected instruction as if it were a legitimate command. This isn’t hypothetical. It’s a documented, active category of attack against agents that read untrusted content and hold real tool access at the same time.

That’s exactly why harness design matters so much. Deciding what a tool is allowed to touch, requiring a human to approve high-consequence actions, logging every call so it can be audited after the fact, none of that is optional. It’s the difference between an agent that’s useful and an agent that’s a liability the moment it reads the wrong document.

What this looks like in practice

If you’ve used Claude, ChatGPT, or Gemini and watched it search the web, read a file, or use another tool before answering, you’ve seen the general idea of tool use in action. The model paused mid-response, requested a tool, got a result back, and folded that result into its answer. Multiply that single tool call by dozens of steps, chained together through the think-act-observe loop from Lesson 4, and you get the multi-step, goal-driven behavior that defines an agent.

What to carry into Lesson 6

Function calling is the mechanism the model requests an action in a structured format, and separate software executes it.
MCP solves the integration problem, one standard connector instead of custom wiring for every tool.
A2A solves a related but different problem of how independent agents communicate with each other.
Tool access raises the stakes of a wrong decision and prompt injection is the specific risk to know once an agent reads untrusted content.

Next lesson, I scale up from a single agent using tools to multiple agents working together, and look at why that’s becoming the default architecture for serious agentic work.