Tools and Function Calling

Lesson 3 named tools as the agent’s hands. This lesson opens up how that actually works under the hood, because the mechanism, 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, in effect, “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 for connecting AI applications with compatible tools and data sources, instead of requiring a completely different integration pattern for every pairing. The shorthand that’s caught on in the industry is that MCP is something like a USB-C standard for AI: a shared connector that makes it easier for AI applications and external systems to work together.

Adoption has moved quickly. By December 2025, Anthropic said more than 10,000 active public MCP servers were in use across the ecosystem. That same month, 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. The goal is to provide neutral governance for open agentic infrastructure rather than having the protocol controlled by a single vendor.

A related protocol worth knowing: A2A

MCP addresses AI-application connections to tools and data. A separate protocol, Agent-to-Agent (A2A), addresses a different problem: how independent agents, possibly built by different companies on different frameworks, communicate and hand off work. 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, effects.

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. Scoping 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 system can request an external capability, receive a result, and use that result in its response. 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.

Carry into Lesson 06

• 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, 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.