Why MCPs are not enough

The widespread use of large language models in consumer settings has fundamentally changed how we work. Most users interact with implementations tied to personal data repositories, public information, and internal training data.

One major limitation to the adoption of deep learning-based AI in the enterprise is the disconnection between these capabilities and the underlying data resources organizations rely on. Multiple statistics show that the average Fortune 1000 company has over 250 unique data repositories used for daily tasks and work. This creates a massive opportunity for large language model deployments. Enter MCPs. 

MCPs, commonly understood as Model Context Protocols, aimed to bridge the gap between data resources that sit within vast repositories and these deep learning-based models. Think of these as LLM-based API connection points. The protocol is gaining traction as first- and third-party developers build tools that language models can use to interact with underlying data sources. In full transparency, Adaly creates many of these tools for the complex structured and unstructured datasets organizations rely on to do their work. One common misunderstanding about MCPs is that the tools integrated into an MCP connector are highly attuned or equivalent to the API calls and data pipelines of the past. Because of the structure of large language models and the nascent intermediary layer between the raw data that most organizations rely on and these models often times, MCPs in the purest of senses are not enough. 

What are some of these limitations? First and foremost, for an MCP to be deployed with high accuracy, the MCP builder must create tools that can retrieve data from different sources in a guided way and serve the underlying LLM. This is not trivial work. Building highly accurate and consistent tools that MCPs can rely on requires the skills and resources of some of the world’s most advanced data science practitioners. This is especially true for structured numerical data which brings me to my second point. What's essential is the output form of the underlying MCPs to be produced in a form that the large language models can use. For unstructured data, this output format is fairly trivial, which is why you see so many MCPs focusing on unstructured datasets like emails and documents. Structured data is complex because converting retrieval data into a suitable structured, quantitative format requires a lot of work. As we've seen, large language models do not do well with this type of data. Especially when that data is voluminous. The third point highlights the need for strong levels of data cleanliness and verification through any pipeline. Whether you’re doing analytics or integrating data from multiple sources horizontally, your pipeline needs robust data cleanliness and transformation tools. Without them, any MCP output will be highly variable. 

MCP work is highly complicated and very specific to each data source you are trying to integrate. Beyond the individual MCPs per data source, there is also a lot of work required to integrate the broader context into cross-data analysis functions.

At Adaly, we have focused specifically on these needs, enabling customers to access their data securely and in real time. More importantly, we provide the appropriate model context protocols for each data source, which supports cross-data analysis. When somebody says, "Oh, you just need an MCP," and they don't talk about the work required to make that MCP highly accurate, available, and contextual, run for the hills.