From Function Calling to MCP: Understanding the Fundamentals of AI Agent Development

Why Understanding MCP Starts with Function Calling

MCP (Model Context Protocol) has become an unavoidable topic in AI agent development, but many beginners quickly get lost in a sea of jargon — MCP, Agent, A2A. In reality, MCP isn't all that mysterious. At its core, it's an optimization and standardization of Tool Calling, a protocol that the industry has gradually converged on. And the foundation of tool calling is Function Calling.

In other words, if you want to truly master MCP and Agent-to-Agent (A2A) collaboration, the most solid path is to first understand how Function Calling works. This technology stack builds layer by layer — jumping straight to high-level protocols without grasping the fundamentals leaves you stuck at the level of buzzwords.

What Problem Does Function Calling Actually Solve

Function Calling was pioneered by companies like OpenAI, and its core purpose is to enable large language models to connect with external tools — translating natural language into API calls.

This addresses a fundamental limitation of LLMs: knowledge staleness. Once a model finishes training, its knowledge is frozen at that point in time. It can't perceive new information that emerged after training, nor can it perform real-world operations that weren't in its training data. Function Calling solves this by allowing a trained model to invoke external or internal functions, gaining access to additional capabilities and real-time data.

A concrete example: a model has no idea what the weather is like today, but if you connect it to a weather query function, it can call that function, retrieve live data, and then answer your question. This is the "superpower" that tool calling gives to LLMs.

Which LLMs Support Function Calling

Virtually all mainstream general-purpose LLMs support Function Calling today. Internationally, Gemini and Claude both support it, and most core versions of leading Chinese models do as well.

One point worth clarifying: DeepSeek's DeepThink (deep reasoning mode) does not support Function Calling, but DeepSeek V3 does. Similarly, certain specific versions of other models (such as some variants of Zhipu GLM) also lack support.

The bottom line: while exceptions exist, Function Calling is effectively a standard capability across mainstream LLMs — and this widespread support is what makes higher-level protocols like MCP viable at scale.

The Five-Step Workflow of Function Calling

Understanding how Function Calling works can be broken down into five clear steps:

Step 1: Define the Function

This is the foundation. You need to clearly describe the function's name, write out its docstring and purpose, and declare its parameters along with their types. The more precisely you describe it, the more accurately the model can determine when and how to call it.

Step 2: Model Reasoning and Decision

Once the function definition is passed to the model, the model performs reasoning to decide whether to call the function. In theory, you can force the model to always invoke a specific function, but the standard approach is to let the model decide autonomously.

Step 3: Generate the Function Call

Once the model determines a function call is needed, it generates a function call. The key output here is the parameters required to invoke the function — the model selects and prepares the appropriate arguments.

Step 4: Actually Execute the Function

Note that the model has only generated a call request up to this point. The actual execution of the function happens in this step.

Step 5: Return Results to the Model

After the function executes, its output is sent back to the LLM, which then uses that result to generate a final answer for the user.

Once these five steps are complete, a full tool-calling cycle is closed.

The Key Difference Between Function Calling and Agents

Many people feel that Function Calling looks a lot like an agent — after all, both involve a model invoking tools to get things done. But there's a fundamental distinction.

The most critical difference lies in decision-making and planning. When an agent makes decisions, it doesn't just determine whether to call a tool — it generates a plan: should it call function A before function B? Should it continue invoking other functions afterward? This produces a multi-step sequence of actions. In contrast, the model reasoning in Function Calling only decides whether a single function should be called — it has no planning capability and doesn't orchestrate subsequent actions.

Another key difference is memory. Function Calling has no memory by default — it's stateless, a simple one-shot invocation that doesn't track context or history. Agents, on the other hand, are typically equipped with memory mechanisms to support continuous, multi-turn complex tasks.

An agent's planning capability is usually implemented through specific reasoning frameworks, the most representative being ReAct (Reasoning + Acting): at each step, the model first reasons (Reason), then decides on an action (Act), then observes the result — repeating this loop until the task is complete. This "think–act–observe" cycle is what enables agents to autonomously complete multi-step complex tasks, a capability that pure Function Calling simply doesn't have. On the memory side, agents typically distinguish between short-term memory (the current conversation context) and long-term memory (historical information stored in vector databases), and some frameworks also support procedural memory (such as learned action sequences). The combination of these memory capabilities allows agents to far exceed the boundaries of single Function Calling invocations when handling scenarios that require accumulating information across sessions and tasks.

From Foundational Capability to Protocol: The Evolution of the Stack

Viewed as a whole, the progression is clear: Function Calling provides the foundational capability for LLMs to connect with the outside world; MCP builds on this with standardization and protocol design, giving tool integration a unified interface; Agents introduce planning and memory, enabling models to autonomously orchestrate multi-step tasks; and A2A (Agent to Agent) goes further into multi-agent collaboration.

For learners starting from scratch, rather than being intimidated by a wall of acronyms, the best approach is to start from the origin point of Function Calling and build your understanding layer by layer. Once you truly grasp the five-step tool-calling loop — and understand how it differs from agents in terms of planning and memory — concepts like MCP and A2A will fall naturally into place.

MCP (Model Context Protocol) was proposed and open-sourced by Anthropic in late 2024. Its core idea is to define a standardized "plug-and-socket" interface for interactions between LLMs and external tools. Before MCP, every company and project had to implement its own tool integration logic, resulting in wildly inconsistent formats and high reuse costs. MCP uses a unified JSON-RPC protocol to standardize how tools are registered, discovered, and called — so a tool only needs to implement the MCP interface once to be usable by any MCP-compatible model or agent framework. Think of it like the USB standard: before USB, device interfaces were all incompatible; after USB, anything conforming to the standard just works plug-and-play. A2A (Agent to Agent) is a further extension introduced by Google in 2025, addressing how multiple agents discover each other, negotiate task assignments, and pass results — essentially adding a layer of "inter-agent communication standards" on top of MCP's "tool-calling standards."