The Difference Between MCP and Function Calling

I had only taken a superficial look at MCP before, thinking it wasn't fundamentally different from function calling and was being overhyped. But these past two days, I went back and took another look, and I've gained some new insights.

Asking an LLM about today's weather

Clearly, an LLM can't answer this kind of question because it can't perceive the external world. However, if we define a function like getweather(day) and explain to the LLM that such a function exists, and that calling it will reveal today's weather by simply passing in a day parameter, then we can pass the parameters, function name, and function description together as a prompt to the LLM, and it will know the information needed to call the function.

Can it really be called reliably?

We know that LLM output is unstable—even the same input can produce different answers. And anyone who writes code knows that if a function name or parameter is off by even one letter, or there's an extra parenthesis, the code will error out and the call will fail.

Therefore, LLMs face the same problem: they don't necessarily output function calls in a neat, standardized format. The LLM might add an extra parenthesis, an extra semicolon, or even ramble on with pleasantries while hiding the call code somewhere in between. This makes it difficult for us to extract the function call statement from the LLM's output.

Teaching LLMs to call functions reliably

To stabilize function calling and ensure the LLM outputs the function name and parameters according to a consistent standard, we can train the LLM specifically for this. When it's time to output a function name, it outputs the function name, and it must be followed by the function's parameters and their values.

Getting LLMs to call more functions

Functions written by different people are hard to unify, and their descriptions vary. Humans can understand them, but LLMs may not.

Through training, an LLM can learn to reliably call functions defined with style A descriptions. But if someone switches to style B descriptions and asks the LLM to call those functions, wouldn't the LLM be lost again and produce unstable output?

MCP unifies the description standard for called functions

Precisely because different people describe functions in different styles and LLMs can't reliably call them, why not just unify the standard style?

Describe functions according to an agreed-upon set of rules—for example, describe the function name first, then the parameter names, and never the other way around. And if the LLM is trained on datasets following this style, it can reliably call functions described in this style. From then on, if everyone describes functions in this style, the LLM can reliably call any newly provided function. Add a stock-fetching function getstocks(xxx) today, add a utility-bill query function getbills(xxx) tomorrow—both can be called reliably without errors.

What about changing function parameters?

We know that code is constantly being refactored and iterated. Take the weather function getweather again—it used to take one parameter, day. Now it's been refactored and upgraded to getweather(day, location), which can not only check the weather for your own IP location but also for other places—just pass in a new location parameter.

But how would the LLM know the function interface has changed? It would take time and effort to manually update the prompt description. That's why MCP uses a client-server model: the client asks the server what the current parameters for this external function are, then passes them back to the LLM. This way, the LLM always knows the latest parameters and no longer has to worry about call failures due to interface changes.

Summary

MCP provides a unified standard for describing and calling external interfaces. In the future, if LLMs are trained on this description standard, they'll be able to reliably call interfaces that conform to the MCP specification—no more worrying about LLMs constantly failing to make calls.

MCP also moves the description of interface parameters from the prompt side to the server side. Instead of hardcoding interface parameters, they're now dynamically fetched. No matter how interfaces are upgraded or changed in the future, calls can be made reliably and successfully.