Model Context Protocol (MCP): Integrating LLMs into Enterprises Efficiently, Scalably, and in a Standardized Way

Not too long ago, the first LLM-based applications were released. They quickly became part of both business and personal workflows. Probably the best-known example of this is OpenAI’s ChatGPT, with its underlying GPT models.

When such an LLM generates output or responses (also known as inference), it can only “see” the tokens (or, simply put, the text) within its context window. This is the model’s short-term memory. It consists of the current prompt, the conversation history, a system prompt, and/or “additional context.” The additional context contains information from sources outside the LLM’s knowledge base, provided by tools the model can access—for example, through queries to knowledge repositories, a Python script, or an internet search.
The right context is therefore crucial for an LLM to generate relevant, plausible, and precise responses. Otherwise, it would sometimes simply “guess”—a phenomenon commonly referred to as “hallucinating.”

Since those first LLM-based applications, many new models have emerged, all of which rely on appropriate context. At the same time, a multitude of new applications built on LLMs has developed. In our projects, we observe that the same use cases often require a significant number of implementations. A popular use case among our customers—and a good example of this—is applications that retrieve and summarize information from corporate files. These capabilities are often provided by what are known as Retrieval Augmented Generation (RAG) systems. However, the flexibility with which these or LLM-based applications are generally implemented often leads to several problems at once; here are a few:

• Reinventing the wheel: Different approaches to the same challenges slow down innovation and incur additional implementation costs. A lack of standardization can also lead to lower reliability, quality, and security in general.
• This results in inefficient use of personnel and infrastructure capacity and drives up integration and maintenance costs.
• These solutions are often developed for specific versions or providers of LLMs. This makes adaptation difficult when new models enter the market or different providers are required. Conversely, integrating a custom-developed resource with other LLM-based use cases can be difficult if the original implementation was not designed for broader integration from the outset.
• All of this leads to a lack of consistent and common interface definitions, which in turn results in a lack of interoperability and compatibility.

This is exactly where MCP comes into play, introduced by Anthropic in 2024:

It is a general interface standard that defines communication and data flow, avoids tool- or resource-specific implementations and redundancies, and enables easy plug-and-play connectivity to LLMs. MCP can thus be viewed in the same light as other technical standards such as Wi-Fi or USB-C, and it enriches the context of an individual LLM by providing additional context through utilities in a generalized manner. These utilities, referred to as MCP servers, are developed exactly once and can be deployed anywhere. They effectively expand a growing list of standard plugins.

Imagine a multinational manufacturing company with multiple production sites in different regions, all connected via an ERP system for inventory management and procurement, as well as databases containing historical production trends. The company’s operations team wants to use AI-based support to make smarter and faster decisions—but with insights based on actual production and supply chain data from various sources.

A business scenario might look like this: A supply chain manager opens the company’s chat interface and asks, “What is the current production capacity utilization in Germany, and what are the implications for inventory management and procurement?”
Instead of a generic response, the assistant tool provides a clear and actionable answer.

“The current production capacity utilization at the German plants is 85%, compared to 78% last week. At this rate, material inventories are expected to be completely depleted in five days. The current lead time for procurement averages seven days, which indicates a potential bottleneck unless order volumes are increased. It is recommended to adjust order volumes or reschedule non-priority production lines.

This is a typical use case enabled by the implementation of a RAG system. We are seeing this frequently at the moment: a virtual chat assistant based on LLMs that utilizes actual enterprise systems to perform its tasks and applies available enterprise information as the fundamental context crucial for effective task completion.

As a foundation for implementing such a RAG system, we can now integrate the enterprise systems using custom logic and API calls. This initially requires time, knowledge of the systems, and communication with system administrators regarding the integration. Second, we may need to consider infrastructure issues such as performance and costs, as well as security aspects. Finally, we must ensure maintainability and long-term compatibility with regard to the integrated systems.
This is where MCP comes into play and demonstrates its advantages: An MCP server is required for each of the underlying source systems in the domain (in this scenario, the ERP system and the databases that provide important additional contextual information about the company). This server must first be implemented in accordance with the MCP standard and can then be made accessible locally or via the cloud. MCP then enables plug-and-play usage in every individual application without having to consider all of the above points again.

The following figure illustrates this for two example applications (App 1 and App 2). The user-specific logic required to connect the various technologies is drastically reduced in the application layer through the introduction of MCP. It is moved to the framework layer, with technology managers responsible for implementing the MCP servers, as they possess the knowledge of the business logic.

For the use case described, this means that the individual efforts required for the implementation and integration of these systems are minimized once the ERP system and the database MCP servers have been set up. They can be easily reused company-wide and scaled centrally, with a clear separation of responsibilities and modularity. This significantly reduces the overall effort required to implement the RAG system for our multinational manufacturing company and, potentially, for all future RAG systems as well.
 

Based on its core structure, the MCP concept naturally enables more autonomous systems that use MCP servers as needed to perform a task. These systems—called agents—can not only utilize additional context but also react to it, plan multi-step solutions, make decisions, and interact purposefully with their environment or other agents.

Several protocols have been developed to facilitate interaction and coordination between agents. Examples of such protocols include the Agent Communication Protocol (ACP) introduced by IBM, which enables the exchange of messages between agents in local environments or within a shared runtime environment, with a focus on data privacy, observability, and seamless operation. Another example is Google’s Agent-to-Agent (A2A) Protocol, which supports real-time communication across domains and cloud environments in a dynamic and loosely coupled manner. Finally, the open-source Agent Network Protocol (ANP) provides a decentralized network layer for agent ecosystems across the entire open Internet. It was designed for future agent marketplaces or similar applications.

ACP, A2A, and ANP address different areas of inter-agent communication and thus enable agents to communicate with one another. In contrast, MCP acts as a standardized context layer for a single agent and focuses on providing internal capabilities to effectively assess, plan, and act in a structured manner using various tools and data.

We have now reached our first stop on this exciting journey, but the next stops will be even more exciting. In this article, we’ve provided an introduction to MCP as a concept—its general approach and advantages, an example use case, and its relationship to agent systems.

In thesecond article, we’ll take a closer look at the structure and concepts of MCP. What do terms like “MCP host,” “MCP client,” and “MCP server” really mean, and how do they fit together? What is the maturity level of MCP, for example, in terms of security and adoption, and where do we see room for improvement? Think of it as the blueprint behind the protocol—revealed.

In Article 3, we’ll conduct a brief reality check. You’ll see how we, the HMS team, are already using MCP to optimize operational processes, implement or improve customer applications, and ultimately deliver smarter services. You can expect practical insights, code snippets, and a brief look at our proprietary code migration tool as well as some customer projects.

In Article 4, we’ll return our focus to agent-based systems and begin with the protocols we briefly mentioned earlier in this article. How do they work in detail? Do they complement each other and thus offer synergies, or do they compete with one another? What are their individual advantages and disadvantages, their use cases, and what general trends are emerging in the market?

The foundation has been laid. The next “stop” is architecture. If you’d like to discuss MCP further, please feel free to contact us. And keep an eye on our blog: We’ll be publishing new articles in this series shortly, featuring both technical deep dives and real-world applications.