Understanding AI Agents: Tool Calling, MCP, and the Agent Loop
How tool calling, MCP and the agent loop fit together into the real architecture of AI agents, starting from the augmented LLM and skipping the buzzwords.
This article is published in English.
Sources: Tool Calling vs MCP: How AI Agents Actually Use Tools
When people start exploring AI agents, the same handful of terms keep popping up everywhere:
Agents. Tools. Function calling. MCP. Context. Memory.
At first glance these look like a pile of unrelated technologies.
But spend enough time digging into how real agentic systems are built, particularly by looking at Anthropic's engineering writeups on agents and MCP, and a much simpler underlying architecture starts to emerge.
This article works through that architecture from a practical, developer-facing angle.
What Actually Makes an AI System an Agent?
A typical LLM-powered app can be drawn like this:
User
↓
LLM
↓
Response
Here, the model just takes input and produces output.
But plenty of real tasks can't be solved by generating text alone.
Take this request as an example:
"Look through this GitHub repository for open issues, dig into whichever one matters most, and give a rundown of what still needs fixing."
To handle something like this, the system has to:
- Understand the request.
- Decide what information it needs.
- Select an appropriate tool.
- Execute the tool.
- Inspect the result.
- Decide what to do next.
- Potentially call another tool.
- Produce the final response.
This is exactly where the notion of an agentic system earns its keep.
Anthropic draws a useful line between workflows and agents.
A workflow moves through a fixed sequence of steps:
LLM → Step 1 → Step 2 → Step 3 → Answer
An agent, on the other hand, figures out on its own which actions and tools to use:
┌──────────────┐
│ LLM │
└──────┬───────┘
│
choose action
↓
Tool
↓
Result
│
└──────────→ LLM
│
choose next action
The key detail isn't just that an LLM is involved somewhere in the pipeline.
It's that the LLM itself has a say in shaping the process.
Anthropic frames agents as systems in which the LLM actively steers its own workflow and tool usage, whereas workflows rely on orchestration logic defined ahead of time by the developer.
The Augmented LLM
One especially useful idea from Anthropic's material is the concept of the augmented LLM.
Rather than picturing an LLM as simply:
LLM → Text
you can picture it as:
┌─────────────┐
│ LLM │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Retrieval Tools Memory
In this view, the LLM gains the ability to reach beyond its own trained parameters and interact with outside information and capabilities.
Anthropic describes retrieval, tool access, and memory as forms of augmentation that turn a plain LLM into a foundational piece for building more capable agentic systems.
This matters because it clarifies that the model itself doesn't magically transform into a full software system.
It's the application wrapped around the model that supplies those extra capabilities.
So What Is Tool Calling?
Before getting into MCP, it helps to look at something more basic.
Imagine giving an LLM access to a tool like:
get_weather(city)
A user then asks:
"What's the weather in Colombo?"
Rather than answering right away, the model can respond with a request to call the function:
{
"name": "get_weather",
"arguments": {
"city": "Colombo"
}
}
The surrounding application is the one that actually runs this function.
That execution might return something like:
{
"temperature": 29,
"condition": "Partly cloudy"
}
This output is fed back into the model's context window.
From there, the model can produce a reply such as:
"It's currently 29°C and partly cloudy in Colombo."
The critical detail here is:
The LLM only decides that a tool should be called. The application is what actually runs it.
The model never opens a direct connection to the weather service itself.
Tool Calling Is Not MCP
This is arguably the single most important distinction to understand in this whole area.
Tool calling and MCP address two different problems.
Tool calling is fundamentally about the exchange between:
LLM
↓
Tool request
↓
Application
↓
Tool result
MCP, by contrast, is a protocol designed to standardize how AI applications connect to external tools, data sources, and context.
Anthropic released MCP in November 2024 as an open standard meant to connect AI assistants to the systems where actual data and tools reside.
According to Anthropic's own documentation, MCP standardizes the way applications feed context into LLMs, and the comparison they use is that it functions like a USB-C port for AI applications.
To sum it up:
Tool Calling
↓
How an LLM requests an action
MCP
↓
How AI applications can standardize connections
to external tools and data
In other words, these two ideas complement each other rather than compete.
What MCP Actually Adds
Picture an AI application that has to reach into:
- GitHub
- PostgreSQL
- Google Drive
- Slack
- the local filesystem
- internal company APIs
- monitoring systems
Without some shared protocol, every one of these connections might need its own custom wiring. You could easily wind up with a setup like this:
AI Application
├── Custom GitHub integration
├── Custom Slack integration
├── Custom PostgreSQL integration
├── Custom filesystem integration
└── Custom internal API integration
MCP steps in by defining a standardized protocol that sits between the AI application and whatever external systems provide capabilities. Conceptually, it looks more like this:
AI Application
│
MCP Client(s)
│
┌───────────────┼────────────────┐
↓ ↓ ↓
MCP Server MCP Server MCP Server
GitHub Database Files
│ │ │
↓ ↓ ↓
GitHub API PostgreSQL Filesystem
With this arrangement, the AI application no longer needs deep, individual knowledge of every backend system. Instead, MCP servers expose their capabilities through a common protocol layer.
The MCP Architecture
MCP is built around a client-host-server model. At a high level, it looks like this:
┌─────────────────────────────────────┐
│ HOST │
│ │
│ AI Application │
│ │
│ ┌──────────────────────────┐ │
│ │ MCP Client │ │
│ └────────────┬─────────────┘ │
└─────────────────┼───────────────────┘
│
│ MCP
↓
┌──────────────────┐
│ MCP Server │
│ │
│ Tools │
│ Resources │
│ Prompts │
└────────┬─────────┘
│
↓
External System
The key roles in this architecture are described below.
Host
The host is the AI application responsible for orchestrating the whole interaction. This could be something like:
- an AI coding assistant
- a desktop AI application
- a developer tool
- a custom-built agent application
MCP Client
The MCP client lives inside the host and is responsible for keeping the connection to an MCP server alive and functioning.
MCP Server
An MCP server is simply a program that exposes capabilities through the MCP protocol. It might expose functionality tied to things such as:
GitHub
Databases
Files
Cloud services
Internal systems
Development environments
Importantly, the MCP server itself doesn't need to be an agent or contain any AI reasoning. Its job is just to make certain capabilities available.
MCP Has More Than Tools
One point that can easily trip people up is assuming MCP is nothing more than a "tool-calling protocol." In reality, MCP defines several distinct primitives beyond tools.
Tools
These are actions that a model is able to invoke, such as:
create_issue()
search_repository()
query_database()
send_message()
Resources
Resources are pieces of information that an application can fetch and hand to the model as context, for example:
file://project/README.md
database://schema
Prompts
MCP can also expose reusable prompt templates as a distinct primitive.
Anthropic's MCP documentation draws a clear line between who controls each of these: tools are controlled by the model, resources are controlled by the application, and prompts are controlled by the user. This layered control is what makes MCP more than just a fancy function-calling mechanism.
A Complete Example
Take a request like:
"Show me the open issues in this GitHub repository."
A simplified version of the resulting flow might look like this:
User
│
│ "Show me the open issues"
↓
AI Application
│
↓
LLM
│
│ decides a GitHub tool is needed
↓
Tool Call
│
↓
MCP Client
│
│ MCP
↓
GitHub MCP Server
│
↓
GitHub API
│
↓
Issue Data
│
↓
MCP Client
│
↓
LLM
│
↓
Final Answer
Notice how many distinct layers are involved here. The model reasons about what information it needs. The application handles orchestration and execution. MCP provides the standardized channel for talking to the external capability. The external service itself carries out the actual work. These are four separate responsibilities, not one blended step.
Where Does Docker Fit?
You'll often see MCP servers packaged and shipped as Docker containers, for instance:
AI Application
│
│ stdio
↓
Docker Container
│
↓
MCP Server
│
↓
External Service
It's worth being clear that Docker itself is not MCP. Docker is just one convenient way to package and run an MCP server. That same server could just as easily run as an ordinary local process or be hosted remotely as a service. The protocol itself is entirely independent from however you choose to deploy it.
STDIO vs Streamable HTTP
MCP works over more than one transport mechanism.
When the integration is local, an MCP client can spin up an MCP server as its own process and talk to it through STDIO.
Conceptually:
AI Application
│
│ stdin/stdout
↓
MCP Server Process
For scenarios where the server lives remotely, MCP relies on Streamable HTTP instead.
AI Application
│
│ HTTP
↓
Remote MCP Server
Because of this, MCP works comfortably whether the tooling sits on a developer's machine or runs as a hosted service somewhere else.
MCP vs REST API
Another distinction worth drawing out is how MCP compares to a plain REST API.
A REST API interaction looks like this:
Application
│
│ HTTP request
↓
REST API
│
↓
Data
An MCP interaction looks like this:
AI Application
│
│ MCP
↓
MCP Server
│
↓
REST API / Database / Filesystem / Other system
Interestingly, an MCP server is free to call REST APIs under the hood.
So MCP isn't there to replace REST.
It's better understood as an AI-friendly layer sitting on top of systems that already exist.
Why MCP Became Interesting
The scale of the integration problem becomes clear once you picture several AI applications each needing to talk to several external tools.
Without a shared protocol, you end up with something like this:
AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database
AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database
Every new pairing of application and tool can mean writing fresh integration code.
A shared protocol reshapes that picture entirely:
MCP
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Slack Database
MCP MCP MCP
Server Server Server
This is essentially why Anthropic released MCP as an open standard instead of treating it as something built only for Claude.
Anthropic has since broadened MCP to support remote servers and wired MCP connectivity directly into its API and products.
But Having More Tools Doesn’t Automatically Make an Agent Better
This is where later engineering work from Anthropic gets genuinely interesting.
It's easy to assume:
More tools = more capable agent.
That assumption doesn't hold up well in practice.
Anthropic's research into tool design shows that agents can actually perform worse when handed too many tools that overlap or aren't designed carefully.
A well-built tool should have a single clear purpose and return useful information while avoiding unnecessary bloat in the model's context window.
As an example, rather than exposing three separate calls like:
list_users()
list_transactions()
list_notes()
it can be more effective to give the agent one combined capability such as:
get_customer_context()
assuming that better matches what the agent is actually trying to accomplish.
In other words, the tool interface itself becomes part of the environment the agent operates in.
Tools Are an Interface for the Agent
That observation points to a broader idea worth highlighting:
Tools ought to be built with the agent in mind, not just repackaged from an existing API.
A conventional API can work perfectly well when a deterministic program is calling it.
An LLM-driven agent, though, operates under a different set of constraints.
It has to contend with:
- a limited context window
- probabilistic outputs
- occasional mistakes picking the right tool
- occasional mistakes generating correct parameters
- ambiguity in what's actually being asked
Because of this, how a tool is described really matters.
Consider how vague this is:
search(id)
versus how much clearer this is:
search_github_issues(
repository,
query,
state
)
For the model to use a tool well, it needs to know:
- what the tool actually does
- when it's the right tool to reach for
- what each input parameter represents
- what shape the output takes
- what the tool can't do
Anthropic's guidance on tool engineering stresses precise naming, clear descriptions, well-specified parameters, useful returned results, and ongoing evaluation.
Context Is Becoming a Major Part of Agent Engineering
Anthropic has also recently emphasized the idea of just-in-time context.
The naive way to handle context looks like this:
Load everything
↓
Put everything into context
↓
Ask the LLM to reason
That approach runs into scaling problems quickly.
A more sustainable pattern looks like this:
Small amount of initial context
↓
Agent identifies what it needs
↓
Tool retrieves relevant information
↓
Relevant information enters context
↓
Agent continues
Rather than front-loading everything the model might need, the agent pulls in information only once it determines that information is actually necessary.
Anthropic has framed this as a move toward "just in time" context handling for agentic systems.
This ties back directly to MCP.
MCP supplies the standardized pathway to external capabilities, while the agent itself decides when to fetch something and exactly what to fetch.
The Agent Loop
Once you put all of these pieces together, the overall architecture starts to make a lot more sense.
A simplified version of the agent loop looks like this:
┌──────────────┐
│ User │
└──────┬───────┘
↓
┌──────────────┐
│ LLM │
└──────┬───────┘
↓
Need a tool?
/ \
No Yes
↓ ↓
Answer Tool Call
↓
Tool/MCP
↓
Tool Result
│
└─────────┐
↓
LLM
│
┌──────────┴──────────┐
↓ ↓
Continue Answer
This loop sits at the center of a large share of agentic systems in use today.
Anthropic frames it in strikingly simple terms: an agent is essentially an LLM calling tools inside a loop, where feedback from the environment shapes what it does next.
The surrounding system built around that loop can grow quite elaborate, but the core mechanism underneath stays this simple.
What About Frameworks?
Frameworks like LangGraph can make building these systems more manageable by giving you structure to work within.
Still, there's an important caution worth keeping in mind.
Anthropic's guidance is to understand what's happening underneath the framework: the raw LLM calls, the tool definitions, the orchestration logic, and the responses, rather than treating the framework as a black box.
A framework typically exposes something like:
Agent
├── State
├── Nodes
├── Tools
├── Routing
└── Execution
But beneath that abstraction, the actual mechanics still look like:
LLM
↓
Messages
↓
Tool calls
↓
Tool execution
↓
Tool results
↓
LLM
Grasping that lower-level flow makes the framework itself far easier to reason about, since you can see what it's automating rather than just trusting that it works.
MCP Does Not Replace Agent Frameworks
It's worth being clear that these are different layers of a system, not competing choices.
A simplified stack might look like:
┌─────────────────────────────┐
│ User Interface │
├─────────────────────────────┤
│ Agent / Workflow │
├─────────────────────────────┤
│ LLM / Model API │
├─────────────────────────────┤
│ Tool Calling │
├─────────────────────────────┤
│ MCP │
├─────────────────────────────┤
│ External Tools / Systems │
└─────────────────────────────┘
An agent framework typically manages things like:
- state
- execution flow
- routing
- loops
- retries
- tool execution
MCP, on the other hand, standardizes how you connect to external capabilities.
Tool calling gives the model a mechanism to request that something be executed.
None of these three are substitutes for one another.
A Few Common Misconceptions
"MCP is an AI model."
Not true.
MCP is a protocol, nothing more.
It has no capacity to generate text or reason on its own.
"MCP replaces function calling."
Also not true.
What actually happens is that an MCP server can expose tools, and an AI application then surfaces those tools to a model through its existing tool-use mechanism.
"The LLM directly calls GitHub."
Typically, no.
The model only produces a request to use a tool.
It's the application and the surrounding tool infrastructure that actually carries out the operation.
"Every MCP server needs Docker."
Incorrect.
Docker is just one possible way to deploy a server.
MCP is concerned with communication and capability exposure, not with how something is containerized.
"An MCP server is an AI agent."
Not necessarily.
An MCP server might just expose plain, deterministic operations such as:
search()
read()
create()
update()
delete()
"MCP is only useful for GitHub."
Far from it.
MCP was built as a general-purpose protocol for linking AI applications to external data and capabilities. Anthropic's original announcement already pointed to integrations spanning systems like GitHub, Slack, Google Drive, databases, and various development environments.
The Bigger Lesson: Agent Engineering Is Not Just Prompt Engineering
This is arguably the most significant shift in perspective that comes out of studying this material.
Building genuinely useful agentic systems is not just a matter of:
Write a clever prompt
↓
Use a powerful model
↓
Get a smart agent
There are several distinct engineering layers involved:
Model
↓
Tool Selection
↓
Tool Definitions
↓
Tool Execution
↓
Context Management
↓
State / Memory
↓
Control / Guardrails
↓
Evaluation
Anthropic's own engineering writing increasingly leans into this wider, system-level view of what building an agent actually requires.
As one example, their recent work on evaluating agents focuses on assessing multi-step behavior, tool usage, changes in state, and adaptation over time, rather than judging quality purely from the final block of generated text.
That represents a meaningfully different way of approaching AI application design.
The Part I Find Most Interesting
The transition that matters here isn't really:
Chatbot → Agent
It's more accurately:
LLM
↓
LLM + Tools
↓
LLM + Tools + External Context
↓
LLM + Tools + Context + Control Loop
↓
Agentic System
MCP slots into that progression by giving AI applications a standardized way of reaching external capabilities.
The model supplies the intelligence.
The application supplies the control.
Tools supply the actions.
External systems supply real-world information and capabilities.
MCP supplies the standardized connective layer linking AI applications to those capabilities.
My Current Mental Model
After working through tool calling, MCP, and Anthropic's broader writing on agentic systems, this is the simplest architectural picture that captures how these pieces fit together:
USER
│
↓
┌─────────────┐
│ LLM │
│ │
│ Reasoning │
│ Decision │
└──────┬──────┘
│
Tool request
│
↓
┌─────────────────┐
│ Agent Runtime │
│ │
│ State │
│ Control Flow │
│ Tool Execution │
└────────┬────────┘
│
↓
MCP / Tools
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Database Files
│ │ │
└────────────┼────────────┘
↓
Tool Results
│
↓
LLM
│
↓
USER
The model, on its own, is not the whole agent.
Neither is a single tool.
Neither is MCP.
What you actually get as "the agent" emerges from the system surrounding the model, the part that lets it reason, take action, observe what happens, and keep working toward a goal.
Final Takeaway
If you're setting out to build AI agents, four concepts are worth mastering thoroughly:
1. Tool Calling
The model can ask the application to execute a specific tool.
2. Agent Loops
The system can repeatedly reason about a situation, act on it, observe the outcome, and continue from there.
3. MCP
A standardized protocol for connecting AI applications to external tools, resources, and context.
4. Tool Engineering
The quality of your tools, their descriptions, their parameters, the context they return, and how well they're evaluated can dramatically shape how well an agent actually performs.
Perhaps the single most valuable lesson to take from Anthropic's engineering practice is this:
Don't add complexity simply because you're able to.
Begin with the simplest architecture capable of solving the problem in front of you. Bring in workflows, additional agents, more tools, memory, MCP servers, and other components only once they deliver a concrete benefit.
The objective was never to build the most elaborate agent possible.
The objective is to build a system that reliably gets the task done.