From Function Calling to MCP: Understanding the Core Mechanics of LLM Tool Invocation

Why Learning MCP Should Start with Function Calling

Many people jump straight into MCP (Model Context Protocol) and Agents, overlooking a critical prerequisite: MCP is, at its core, an optimization and standardization of tool calling. It still relies on Function Calling under the hood — MCP simply formalizes that mechanism into a widely adopted protocol.

In other words, without a solid grasp of Function Calling, it's hard to truly understand MCP, let alone the higher-level Agent to Agent (A2A) communication model. That's exactly why this tutorial series starts with Function Calling — lay the foundation before building the house.

Function Calling was pioneered by companies like OpenAI. It allows LLMs to connect with external tools, translating natural language into API calls. The core problem it solves is this: once a model finishes training, its knowledge is frozen — it can't access information generated after the training cutoff. By calling external or internal functions at inference time, the model gains additional capabilities and access to real-time data.

Most mainstream general-purpose LLMs today support Function Calling. The tutorial clears up a common misconception: DeepSeek R1 does not support Function Calling, but DeepSeek V3 does; OpenAI's GPT series supports it broadly as well. The vast majority of mainstream models have this capability.

MCP (Model Context Protocol) is an open protocol proposed and open-sourced by Anthropic in late 2024. Its goal is to define a unified standard for interactions between LLMs and external tools or data sources. Before MCP, different platforms (OpenAI, Anthropic, Google, etc.) each implemented tool calling differently, forcing developers to write separate integrations for each platform — a significant maintenance burden. MCP's core value proposition is "describe once, call anywhere": tool providers expose interfaces according to the MCP spec, and any MCP-compatible model or Agent framework can automatically discover and invoke those tools without custom adaptation. A2A (Agent to Agent) sits at an even higher level, describing how multiple agents communicate and collaborate — and it too depends on the underlying function-calling mechanism to pass instructions and results. Understanding this evolution from Function Calling → MCP → A2A is essential groundwork for learning modern AI application development.

The Five-Step Function Calling Workflow

The tutorial breaks the entire process into five clear steps — the skeleton for understanding all advanced concepts that follow:

Step 1: Define the function. Describe the function's name, document its purpose, and specify its parameters and types. This is how the model learns what tools are available.

Step 2: Model reasoning. The LLM decides whether to call a function for the given request. You can force it to always call a function, but that's generally not recommended.

Step 3: Generate a function call. Once the model decides it needs to invoke a function, it generates a function call instruction — the most important part being the preparation of the required arguments.

Step 4: Execute the function. The developer's code actually runs the function. The model itself does not execute anything.

Step 5: Return the result. The function's output is passed back to the LLM, which then generates the final natural language response.

Here's a subtle but important distinction: Function Calling and Agents may look similar, but they're fundamentally different. An Agent generates a plan when making decisions — for example, deciding whether to call function A before function B, or whether additional tool calls are needed afterward. Agents have planning and memory capabilities. In contrast, Function Calling only asks: "Should this function be called right now?" — no planning, and no memory by default. This difference is key to understanding Agents later.

Worth noting: the entire Function Calling process involves two network requests. The first asks the model to decide whether to call a function and generate the call instruction. The second sends the function's execution result back to the model so it can produce a final natural language answer. This two-phase structure is something many beginners miss — and it's what distinguishes Function Calling from a regular API call. The model's role is purely "decision-making" and "summarization"; the actual computation or data retrieval always happens on the developer's side. Additionally, the tool_choice parameter controls invocation behavior: auto lets the model decide whether to invoke a tool, required forces a tool call every time, and none disables tool calling entirely. In production, auto is the most common setting, allowing the model to make context-aware decisions and avoid unnecessary latency and cost.

Weather Query in Practice: Walking Through a Complete Function Call

The tutorial uses a real-time weather lookup as its demo scenario — a classic choice, since LLMs have no access to live weather data and must rely on an external function.

The first step defines get_weather, which accepts a location parameter (a city or region). The demo doesn't implement actual weather retrieval logic — it returns mock JSON data — because the goal is to fully illustrate the Function Calling mechanism itself.

Next, the model is wired up using OpenAI's native API (with the API key managed via .env and a domestic proxy configured as the base_url). After creating a client, the code calls client.chat.completions.create. The model is set to the more affordable gpt-4o-mini, and the messages array contains the user's input: "What's the weather like in Beijing today?"

The critical piece is the tools parameter: the previously defined function must be converted into a JSON-format tool description. This JSON object includes the type (function), the function name, a description, and a parameter schema — with properties defining location (its type and description) and required indicating which parameters are mandatory. The tutorial repeatedly emphasizes: write the description clearly, because that's exactly what the model uses to decide when to invoke the tool.

There's also the tool_choice parameter: set to required to force a call, or auto to let the model decide. The demo uses auto.

Dissecting the Model's "Call Instruction"

After running the code, the model returns a ChatCompletion object. At this point, the function has not actually been executed — what the model returns is an instruction to call the function.

You retrieve this instruction via response.choices[0].message.tool_calls, which returns an array (in this case, just one entry). Each tool_call contains a function object with two key fields: name (the function to invoke, get_weather) and arguments (the parameters the model has prepared, e.g., location=北京).

Once the instruction is in hand, the code: parses the function name, uses json.loads to convert the arguments string into a dictionary, and extracts location. A guard check follows — if the function name equals get_weather, execute the local function and capture the result.

For the final step, the tool call information and its result are appended to messages, and a second request is sent to the model. The model uses this context to generate a natural language response along the lines of "Today in Beijing, the temperature is… and the wind is…" — completing the full five-step cycle.

Why No One Writes This Code by Hand Anymore

The tutorial closes with a candid observation: this manual approach to Function Calling exists only to help you understand the underlying mechanics. In real-world development, nobody writes it this way.

The instructor is direct: while someone might have coded this at the low level in the early days, today's LLM development baseline is building Agents — not manually handling every function call step by step. This circles back to the opening thesis: Function Calling is the foundation, MCP is the standardization layer, and Agents and A2A are the application forms built on top.

Understanding this evolution clarifies exactly what MCP improves: it takes the previously fragmented, platform-specific tool-calling implementations and converges them into a unified protocol — one where tools can be discovered, described, and invoked in a consistent, standardized way. And it all starts with the Function Calling mechanics dissected in this lesson.

Today's mainstream Agent frameworks — LangChain, LlamaIndex, AutoGen, and OpenAI's Assistants API — all encapsulate the complete Function Calling workflow internally. Developers simply declare tool names and descriptions; the framework automatically handles building the tool list, parsing model-returned instructions, dispatching function execution, and returning results. In LangChain, for example, the @tool decorator is all it takes to register a Python function as an invokable tool — the Agent handles all five intermediate steps automatically. This abstraction dramatically lowers the barrier to entry. But precisely because of this, many developers find themselves stuck when debugging issues or needing to customize behavior, simply because they don't understand what's happening underneath. Walking through a complete Function Calling flow by hand is exactly what gives you that mental model when working with high-level frameworks.

Summary

The value of this lesson isn't in teaching you how to write production code — it's in building the right mental model: the five-step Function Calling workflow, its fundamental distinction from Agents, and its role as the underlying mechanism for MCP. With these concepts in place, when you move on to MCP and multi-agent collaboration, you won't be stuck at the "can use it but don't understand it" level.