The Danger of MCP - What Every Developer Needs to Know 🚨

It sounds like a smart solution. It promises efficiency and new possibilities. And yet very few people are talking about it. MCP is being integrated everywhere right now. Quickly, conveniently and seemingly harmless. But what if that's exactly where the problem lies?

What if we’re adopting a system that changes our applications, strains our models and increases our costs without us even realizing it? What if every integration is a decision that could cost us dearly in the long run?

In this article we’ll take a close look together. And I’ll show you why MCP isn’t just a new protocol but a technical risk that very few have truly understood so far.

Remember the ChatGPT Plugins?

In 2022 OpenAI introduced ChatGPT plugins for the first time, initially in a preview version available only to paying users. A plugin store was added offering useful extensions including the popular WebPilot plugin. It allowed the model to browse the web based on your prompts and deliver up-to-date information.

Those wanting to develop their own plugin could rely on well-documented guidance provided by OpenAI.

Now imagine you're a software provider who wants to develop a plugin that gives your customers direct access to always up-to-date content from your documentation via ChatGPT. The AI would then respond to questions as if it were specifically trained on your product. Sounds like real added value, right?

A Similar Approach with GitHub Copilot

The same concept exists for GitHub Copilot through what are called Copilot Extensions. These rely on an additional API embedded into the Visual Studio Code extension API. So if you want to integrate your solution there too you'll need to get familiar with yet another interface.

The result: your customers can ask questions about your product directly in the GitHub Copilot chat and get solutions right from the editor. A clear advantage but also double the effort. Because now you're managing two separate plugin systems on top of your regular workload.

And that’s not all. You could also go through the same process for Perplexity, Le Chat by Mistral, Claude Desktop, and many other AI platforms.

And this is where the real problem begins.

🚩 A Fragmented Ecosystem

Every platform has its own way of allowing extensions. The company Anthropic, which developed the powerful Claude model, for example wants to enhance its Claude desktop app with plugins. But it quickly realized the major hurdle. Developers are increasingly frustrated with the jungle of APIs and integrations.

Welcome MCP

This was the moment when the idea of a unified standard for AI plugins was born. Its name is MCP, the Model Context Protocol.

The basic idea sounds almost too good to be true. Instead of developing a separate plugin for each AI platform, one plugin will be enough in the future. It will be hosted through something called an MCP server. Tools like ChatGPT, GitHub Copilot or Claude Desktop act as MCP clients. All of them access the same plugin.

The concept is strongly reminiscent of the USB standard. Plug it in once and it just works. Here too, your plugin is supposed to connect like a USB stick, regardless of which AI tool is being used. The integration happens automatically with no extra adjustments required.

At this point, it's easy to see why MCP is currently being celebrated as a real game changer. The vision is simple. The benefit is obvious. And if everyone stuck to this standard, it would indeed be a huge leap forward.

But amid all the excitement lies a nearly invisible component. A subtle dose of risk that hardly anyone notices until it's too late. Its toxic effect unfolds quietly and gradually. And that is exactly where the real danger of MCP lies.

⚙️ The Thing About Function Calls

To understand where the real danger behind MCP lies, we need to go back to the basic idea of plugin integration for a moment. OpenAI was one of the first companies to introduce a new feature that is central in this context. It’s called Function Calling.

When communicating with the OpenAI API, you can register your own functions that the language model is allowed to use. These functions are described according to a fixed schema. With every input, the model checks whether one of these functions could provide additional information that would be helpful for the response.

However, the model does not execute the function itself. Instead, as developers, we receive a structured JSON response. This tells us which function should be called, along with the parameters. We then perform that call in our own code, whether in C Sharp, JavaScript or Python, and return the result to the model. The final answer sounds as if the model had always known that information.

Modern AI APIs now handle this so-called roundtrip automatically in the background. In many cases we don’t even notice that functions have been executed during the conversation.

For example, in LangChainJS you need to explicitly check whether the model wants to call any functions at all. You pass an array of possible tools. If there’s no function call, the dialogue continues as usual.

My personal favorite is Semantic Kernel in .NET. There you simply annotate methods with an attribute. The whole process happens almost invisibly. Only a breakpoint during debugging reminds you that a function was triggered behind the scenes.

🕵️ The Dark Side of Function Calling

Function Calling is without a doubt a powerful tool. Especially in RAG systems, where custom knowledge sources are integrated into the AI, it unleashes its full potential. But like with any technology, it’s worth taking a closer look at the downsides. And in the case of Function Calling, they’re not to be underestimated.

1. It Costs Money – More Than You Might Think 💸

Even the communication between the language model and the registered functions generates ongoing costs. Every function description counts as input tokens. And cloud providers charge for those tokens, both incoming and outgoing.

It gets even more expensive when the language model actually decides to execute a function. At that point, additional costs are incurred for what would otherwise be a simple dialogue. In longer conversations, this can escalate quickly.

The solution is obvious. Only register functions that are truly relevant to the current conversation. Ideally, functions should be flexible enough to cover multiple tasks instead of creating a separate function for every little thing.

2. Loss of Control 🎮

Another issue is the growing loss of control. Take a function that provides the current time. If the user explicitly asks for the time, it's clear that this function should be called. But there are many implicit scenarios too. For example, if the model is expected to provide the current weather along with the time. That requires multiple functions to be combined correctly.

And that’s exactly where the challenge lies. The more functions you register, the harder it becomes for the model to make the right decisions. It forgets about relevant functions or calls the wrong ones. And that means double the cost without real added value.

Even OpenAI notes in its official documentation that only essential functions should be registered. Twenty functions is already considered the upper limit. Beyond thirty, reliability drops significantly.

3. Language Quality Suffers Noticeably 📉

Every new language model gets praised for being able to process more context. But anyone familiar with the underlying architecture knows that more context doesn’t necessarily mean better results.

Imagine a sheet of paper with several sentences written on it. Each sentence belongs to a different topic area. The language model has to figure out which context is most important for the current user input.

A simple example:

• First, finely chop the onions.
• Then add some olive oil to the hot pan.
• Meanwhile, a light rain tapped on the windowsill outside.

The first two sentences clearly belong in a cooking context. The third adds atmosphere but belongs in a different context. When a prompt is given, the model has to determine which of these is relevant for the response.

Longer prompts and complex conversations amplify this issue. Studies show that LLMs don’t process information equally well across long texts. In particular, content in the middle of a prompt is often neglected.

That’s exactly what happens with Function Calling. When too many functions are registered, the conversation context gets bloated right at the beginning, even if the actual dialogue is short. This makes it harder for the model to prioritize relevant information and degrades the quality of its responses.

Two recent studies confirm this clearly:

• The CallNavi study shows that as the number and complexity of functions increase, LLMs struggle more with choosing the correct function calls.
• ComplexFuncBench confirms that accuracy drops significantly with nested and multi-step function calls.

These findings lead to a clear conclusion: less is often more. A leaner context results in more precise outcomes, both in language quality and in function integration.

🧩 What Does This Have to Do with MCP - Where Does the Real Danger Lurk

We’ve seen that Function Calling offers many benefits but also comes with serious drawbacks. The biggest risk is that these problems often creep in unnoticed. Many developers integrate function calls without considering the long-term consequences.

And this is where it gets critical. Because at its core, MCP is built on Function Calling. An MCP server provides a structured JSON document that describes all available functions. These functions can then be executed through the corresponding MCP client. Clients include AI systems like ChatGPT or GitHub Copilot.

Here’s the catch: many MCP servers already provide far more than twenty functions right from the start. Articles often celebrate the fact that multiple MCP servers can be connected at the same time. But what’s often forgotten is that every additional integration automatically increases the number of registered functions. And with that, costs rise significantly.

Because as we know, every registered function adds token load. The more functions are registered, the more expensive each individual conversation becomes. And it’s the user making the request who ends up paying for it, often without knowing why the costs are suddenly going up.

But that’s not all. From a security standpoint, this is also highly problematic. An untrustworthy MCP server can be just as dangerous as a USB stick with hidden malware. Such a server could use a function definition to gain access to chat histories or launch targeted attacks through so-called prompt injections.

What makes this even more critical: in the current MCP version one specification, there are no built-in security mechanisms. There are no safeguards against abuse or manipulation. Anyone integrating MCP today may be opening the door to potential vulnerabilities that hardly anyone is addressing yet.

✅ Conclusion

This article is not meant to discredit MCP as a whole. Quite the opposite. The idea behind the Model Context Protocol is brilliant. Develop one solution and integrate it across multiple AI systems, that sounds like every developer’s dream. Just as the USB standard simplified our digital world, MCP promises an elegant form of unification.

But just as we’ve learned not to blindly trust unknown USB sticks, we should take a closer look at MCP. Many developers don’t realize the risks that come with connecting an MCP server. These servers are often adopted without review. The danger becomes even greater when AI services start integrating them automatically. That’s when we open the proverbial Pandora’s box.

A clear role model here is Visual Studio Code with GitHub Copilot. When an MCP server is added, the interface immediately shows a list of all available functions. What matters is that you consciously activate only the functions you really need.

Even better: when a function call is about to be triggered, GitHub Copilot actively asks the user. A simple but important security measure. The message basically says: I’m about to execute a specific function on the MCP server based on your prompt. Do you really want to allow this?

Claude Desktop shows similarly good behavior. Unfortunately, that’s not the case with many API-based solutions in LangChainJS or the Semantic Kernel. There, all functions are automatically registered and executed without confirmation. For attackers, this is a golden opportunity.

Not coincidentally, on April 9, 2024, OpenAI removed ChatGPT plugins. They worked in a very similar way. The reason given was simple: for security reasons.

So if you want to use MCP in your own solution, take Visual Studio Code as a model. And if you’re just a user of MCP, make conscious choices about which servers you really trust. Because in the end, you're plugging nothing less than a foreign USB stick into your system.

💡 What’s your take on this?

🔁 Share this with your team if you’re working with AI integrations

💬 Have you faced unexpected costs or behaviors using Function Calling or MCP?

🤔 Would you trust a third-party MCP server without checking what it exposes?

👇 Let’s discuss in the comments. I'm curious how you handle this in your stack.

Takeaways

• MCP is technically brilliant but should be handled with caution
• Function calls come with hidden costs and risks
• Security should always come before convenience
• Just because something works automatically doesn’t mean it’s automatically safe

🧠 If you only remember 3 things:

1. MCP relies on Function Calling, and that comes with hidden complexity and cost

2. Integrating MCP blindly opens doors to uncontrolled risks and potential security flaws

3. Just because it works automatically doesn't mean it’s safe or smart

🎥 Watch the full MCP deep dive in my Twitch livestream recording on YouTube (German only): https://youtu.be/L7zfd7AAnkc

🔧 For secure and structured management of function calls in Semantic Kernel, check out my open source solution Semantic Flow: https://github.com/GregorBiswanger/SemanticFlow

#MCP #GenerativeAI #OpenAI #GitHubCopilot