How AI Agents Use Tools and MCP to Take Action

TL;DR

Foundation models can reason brilliantly but cannot natively call APIs, send emails, or fetch real-time data, so tools act as an agent's senses and actuators. The Model Context Protocol (MCP), an open standard introduced in 2024, decouples the reasoning agent from the tools doing the work, solving the fragmented n-times-m custom-connector problem and enabling plug-and-play integration.

Transcript

Okay, so today we're diving into uh what feels like the core question for anyone working with AI right now. How do you get these incredibly smart language models to actually do something useful in the real world? Right? Because a powerful foundation model, I mean, it's brilliant, but it's fundamentally stuck inside its training data, you know? Yeah... Read More

Key Insights

• Tools are functions or programs that let an LLM-based application do what the model cannot natively do, falling into two buckets: letting the model know something new (like fetching a weather forecast via API) or letting it do something (like sending a message or updating a database).
• The n-times-m problem historically made tool integration a fragmented mess, because connecting n different models to m different tools required bespoke custom connectors for every single pair, which did not scale.
• The Model Context Protocol (MCP), an open standard that emerged in 2024, streamlines integration by decoupling the agent (the brain or reasoner) from the specific tool doing the work (the actor), enabling a unified plug-and-play connection.
• Function tools are external functions developers explicitly define, often in Python, using detailed docstrings that define the contract of inputs and outputs so the model reads that documentation to figure out how to call the function correctly.
• Built-in tools are provided implicitly by the model service provider and work behind the scenes, such as Gemini using Google Search for grounding, executing code itself, or fetching content from a URL.
• Agent tools invoke another separate agent as if it were a tool, but the primary agent stays in charge, calls the sub-agent, gets a result back, and uses that result as an input for its own reasoning, making it delegation rather than a full transfer.
• Documentation is paramount because the name, description, and parameters are fed directly into the model's context, and tools should describe the action rather than the implementation, letting the LLM reason while the tool simply acts.
• MCP borrows its architecture from the language server protocol (LSP) and uses three pieces: the MCP host that orchestrates and enforces safety guardrails, the MCP client that maintains the connection and sends commands, and the MCP server that advertises and executes tools.

Questions & Answers

Q: Why can't foundation models take actions in the real world on their own?

A powerful foundation model is fundamentally stuck inside its training data, described as an amazing pattern matching machine that is completely isolated from anything current or anything it can act on. It is like having memorized every book in the library but having no hands or eyes. It can write code or generate amazing text, but it cannot call an API on its own, check a real-time stock price, or even send an email. Tools give the model the ability to perceive and act, which is what makes Agentic AI potentially revolutionary, especially inside businesses in the enterprise.

Q: What is a tool in the context of AI agents?

Fundamentally, a tool is just a function or a program that an LLM-based application uses to do something that the model itself cannot do natively. These tasks fall into two main buckets: either letting the model know something new, like fetching a real-time weather forecast using an API, or letting the model do something, like actually sending a message, updating a database, or making something happen in the outside world. In short, tools let a model either know something or do something it could not otherwise accomplish, acting as the agent's senses and actuators.

Q: What is the Model Context Protocol (MCP) and what problem does it solve?

The Model Context Protocol, or MCP, is an open standard that came about in 2024 to streamline the integration of tools with AI agents. Historically, connecting n different models to m different tools created an exponential n-times-m problem, a fragmented mess of custom code and bespoke connectors for every single pair that did not scale. MCP provides a unified, almost plug-and-play way to connect tools, fundamentally decoupling the agent, the brain or reasoner, from the specific tool doing the work, the actor. It is inspired by the language server protocol (LSP).

Q: What are the three main types of tools developers use with agents?

The white paper breaks tools into three categories. Function tools are external functions developers explicitly define, often as Python code with detailed docstrings that define the contract of inputs and outputs, such as a set light values function needing brightness and color. Built-in tools are provided implicitly by the model service provider and work behind the scenes, like Gemini using Google Search for grounding or executing code. Agent tools invoke another separate agent as if it were a tool, where the primary agent stays in charge and uses the sub-agent's result as an input for its own reasoning.

Q: How does an agent tool differ from simply handing off a task to another agent?

An agent tool means you are invoking another separate agent as if it were a tool, but the key distinction is that you are not completely handing off the conversation or the main task. Your primary agent stays in charge, calls the sub-agent, gets a result back, and then uses that result as an input or resource for its own reasoning, often managed with an agent tool class in an SDK. It is more like delegation than a full transfer and is hierarchical, like a manager asking a specialist team for a report rather than forwarding the whole project to them.

Q: Why is documentation considered the most important best practice when building tools?

Documentation is paramount because the only way the model knows what your tool does, what it needs, and what it returns is through the documentation you provide, including the name, description, and parameters. This information is literally fed into the model's context, so clarity is key. You should use clear, descriptive names, since a name like create a critical bug with priority is infinitely better for the model than something vague like update Jira. The name and description essentially become the instruction manual for the LLM, so specificity directly determines whether the tool is used correctly.

Q: How should tool output be designed to avoid degrading an agent's performance?

Tools should be designed for concise output. If a tool pulls down a massive spreadsheet or huge log file and stuffs it all back into the LLM's context window, you get context window bloat, which eats up tokens that cost money, increases latency, and actually degrades the LLM's ability to reason because it wades through irrelevant data. Instead of returning raw data, return a concise summary, a confirmation, or better yet a reference like a URI pointing to where the full data is stored externally. Systems like Google ADK's artifact service are built for exactly this.

Q: What are the three components of the MCP architecture and what does each do?

MCP borrows its client-server idea from the language server protocol and uses three main pieces. The MCP host manages the overall user experience, orchestrates the agent's thinking, decides when tools are needed, and acts as the enforcer applying safety guardrails and policies, like a traffic cop. The MCP client is embedded within the host as a dedicated communication module that maintains the connection to the server, manages the session lifecycle, and sends commands to execute tools. The MCP server is the actual program providing the tools, advertising what it offers, executing commands, and sending results back.

Summary & Key Takeaways

• A powerful foundation model is brilliant at pattern matching but stuck inside its training data, isolated from anything current or actionable. It can write code or generate text but cannot call an API, check a real-time stock price, or send an email. Tools give agents the senses and actuators, the eyes and hands, needed to perceive and act in the real world.

• The white paper from Google and Kaggle's 5-Day AI Agents Intensive defines three tool types: function tools that developers explicitly define with docstrings, built-in tools provided implicitly by the model service provider like Google Search grounding, and agent tools that invoke another agent as a resource while the primary agent stays in charge and composes capabilities hierarchically.

• Best practices for building reliable tools include making documentation paramount, describing the action not the implementation, publishing high-level tasks instead of raw API wrappers, designing for concise output to avoid context window bloat, and returning descriptive, instructive error messages. MCP standardizes tool use across a host, client, and server so developers can focus purely on reasoning.