Model Context Protocol as the Future of Data Engineering

4 min read

Originally published on Medium.

Integration of MCP within enterprise organizations creates a new demand for data engineers with a unique combination of data and generative AI skills. While it may sound like a familiar claim — companies have been trying to connect data to GenAI using concepts like “chat-to-your-data” for many years — Model Context Protocol makes this process more streamlined, enabling plug-and-play capabilities for cutting-edge companies as well as those with a low level of AI adoption.

An MCP server connected to data provides not only an elegant way to enable cross-company access to data, but also brings new challenges, as outlined below.

Generic MCP Implementation

A generic MCP server connected to a data platform allows a straightforward way to connect chatbots and other MCP clients to data and its infrastructure. However, such generic MCP servers provide their capabilities without domain-specific knowledge.

For example — a basic MCP easily handles “Show all database tables with customer information,” but cannot effectively interpret “What’s our customer churn risk based on recent support tickets?”

The lack of domain knowledge in generic MCP servers poses a challenge for queries that require domain-specific contextual understanding — the ability to translate business terminology into appropriate data queries and meaningful insights. Just as connecting a BI reporting tool to a database through JDBC requires specialized knowledge to build business-oriented dashboards, the MCP server requires extra domain knowledge to integrate with tools used by business users.

Business-Oriented MCP Implementation (MCP-as-a-Product)

The real power of MCP and its potential ROI emerge when we empower MCP with business knowledge. The appeal of this approach is that the business can now interact with data through natural, complex queries that reflect actual decision-making processes.

“Show me the latest actual company revenue and compare it with forecast numbers for the next six months. Connect it with the current status of the project and produce a structured summary highlighting discrepancies.”

A generic MCP server cannot truly serve a query like this. A domain-focused implementation includes: a refined dataset governed by data governance, and a business-oriented MCP server with tools tailored to actual business needs, rather than generic functionality.

The Challenge: Beyond Traditional Data Engineering

While the concept of a business-oriented MCP server may seem challenging, seasoned data engineers have long addressed similar problems through refined BI reporting layers (data marts, aggregations, analytical layers, etc.). A conversational AI introduces new challenges on top of that:

MCP Client Limitations

Unlike traditional BI tools with predefined reports and dashboards, an AI-powered conversational interface may have context and prompt interpretation issues. Data engineers can’t simply provide a subset of data marts and expect the model to always correctly interpret every query variation. The system must be adaptable to the full spectrum of potential questions.

Example: the same intent phrased differently can hit different tables and return different results:

• “What were our top 5 products in Q4 2024?” → hits sales_summary_qtrly using a fixed product ranking
• “Which products had the most revenue in the last quarter?” → triggers revenue_by_product_daily with recent data

Data Governance and Business Context

MCP systems require robust data governance and descriptive metadata layers. Without expert-level understanding of data semantics, relationships, and business context, even the most advanced AI models cannot correctly identify, interpret, or present the right information.

Example: AI is asked “Show churn rate per region” but the customer_status column uses internal codes like INAC, DEL, SUS — not easily interpretable without a semantic layer.

Department-Specific Adaptations

Just like BI dashboards vary by department, MCP will require different views and interpretations of the same data:

• Finance asks “Show cost per unit” → expects full overhead and amortization included
• Operations asks “Show cost per unit” → expects raw material + labor only

Model Context Limitations

This is especially relevant for big data datasets. MCP servers should be ready to return data that can fit into the model’s context window and be meaningful.

Example: “What are common error patterns in device logs from last year?” — the device logs span 6 TB and over 12 billion rows. The data exceeds the model’s context window, leading to misinterpretation and repeated requests that burn both tokens and infrastructure resources.

Data Engineering and Generative AI — Fusion or Collision?

The successful implementation of an MCP product creates a new demand for engineers at the intersection of generative AI and data. The best path forward is to bridge traditional data engineering with generative AI capabilities: semantic layer and data design integrated into prompt engineering; data quality merged with evaluation frameworks.

Conclusion

The future of data engineering is not only about managing data — it’s about making data accessible, context-ready, and conversational for business users. MCP adoption at the company level will significantly accelerate this process and will require data platforms to support cross-functional teams and engineers prepared for this shift.

This is not a threat — it’s an opportunity for data engineers to evolve from pipeline engineering into data and conversational architecture, and for companies to evolve into data-driven AI organizations.