The conversation around agentic AI is increasingly gaining momentum, particularly as large language models (LLMs) evolve from passive interfaces into active participants in software ecosystems. These new systems—more commonly known as agentic applications—are characterized by the model’s ability to autonomously make decisions, invoke external tools, and coordinate complex workflows based on natural language instructions.
As the landscape moves towards this direction, the need for structured, repeatable, and scalable integration has become bigger than ever.
One such mechanism is the Model Context Protocol (MCP), a standardized foundation for interoperability frameworks for agentic AI applications. MCP is not a product, nor is it an AI framework. It is, fundamentally, a communication protocol, a way to describe, expose, and invoke capabilities offered by a system, enabling interoperability between components within an AI-driven ecosystem.
This blog post explores some key components of MCP, how it operates, and how its application can significantly improve the interaction between LLM agents and data products, particularly in architectures that follow the data mesh paradigm.
MCP provides a standardized, scalable way to address Agentic AI's requirement of reliable, consistent access to data and services across multiple domains and teams.
At its core, MCP formalizes a client-server model where the agentic application - driven by an LLM - acts as the client, and any external system it interacts with acts as the server. The server is responsible for exposing a list of available functions (called tools) through a discovery endpoint, alongside machine-readable descriptions of these tools that are intelligible to the LLM.
Based on a client-server model, MCP enables LLM agents to discover and interact with tools through standardized protocols, similar to how USB-C standardized peripheral connections.
This discovery endpoint plays a critical role: it defines the surface area of what the server offers and provides semantic context to help the LLM determine when and how to use a given tool. The descriptions, while returned in a structured JSON format, are often expressed in natural language and metadata combinations, ensuring that the LLM has enough information to reason about the function’s purpose and applicability.
MCP’s approach is intentionally non-prescriptive in terms of content. It only dictates the interaction model and message structure - not the internal implementation, data model, or semantics of the tools themselves. This flexibility makes it applicable to a wide range of use cases, including those where systems are built on different stacks or standards but still need to interoperate seamlessly with agentic clients.
MCP is not a product, nor is it an AI framework. It is a communication protocol: a way to describe, expose, and invoke capabilities offered by a system, enabling interoperability between components within an AI-driven ecosystem.
Traditionally, integrating an LLM into a business process requires custom development: for each external system an agent must interact with developers need to define bespoke function schemas, handle authentication, and manage error handling in a tightly coupled manner. This reduces flexibility and limits scalability.
By contrast, MCP introduces a common protocol layer between agents and external systems. The protocol facilitates standardized communication protocols for LLM agents through well-defined endpoints that expose capabilities in a consistent way.. The agent queries the discovery endpoint, reads the tool definitions, and determines which ones are useful for its current task. Tool invocation then follows a standard interaction flow defined by the protocol.
This standardization has the potential to accelerate the deployment of agentic architectures in enterprise environments, where governance, modularity, and system interoperability are essential.
One area where MCP shows significant promise is in its potential integration with data products, particularly those implemented within a data mesh architecture.
MCP integration with data mesh architecture creates powerful synergies, allowing domain-oriented data products to expose capabilities through standardized interfaces
In a data mesh, data products are designed to be autonomous, interoperable, and managed by domain teams. They expose several interfaces, typically structured around three types of ports:
These interfaces already serve as a boundary for programmatic interaction. When combined with MCP, they can be made natively accessible to LLM agents, enabling new layers of automation and orchestration.
An immediate and straightforward application is the exposure of output ports—i.e., access to datasets or derived metrics—as tools in an MCP server. This allows agents to discover and retrieve data without prior hardcoding. These tools may range in granularity from narrow task-specific endpoints (similar to REST APIs) to more general-purpose query interfaces that describe the schema and metadata, akin to GraphQL or SQL-over-HTTP endpoints.
This model enables agents to perform intelligent data selection, filtering, and transformation based on the metadata exposed. Furthermore, it fosters decoupling between the agent and the data source, as the interface is discovered at runtime, not defined at design time.
| Without MCP | With MCP |
|---|---|
| Custom development required for each system integration with bespoke schemas, authentication, and error handling, reducing flexibility and limiting scalability. | Common protocol layer allowing agents to discover and interact with any MCP-compatible system using standardized tools and interaction flows. |
Observability ports, which provide metadata on the state and quality of data (e.g., freshness, completeness, latency), gain new utility in agentic contexts. These ports are generally used to implement threshold-based checks—for instance, verifying whether a dataset is less than one hour old. While still effective, this approach lacks adaptability.
Agents can use observability information in a context-aware manner, factoring in their specific objectives. For example, an agent generating a monthly report may tolerate lower freshness thresholds than one producing real-time operational metrics. This approach supports autonomous decision-making in data product ecosystems without compromising security or compliance requirements.
Control ports are interfaces that allow external systems or users to trigger operations on a data product, such as restarting a pipeline, triggering data deletion for compliance, or initiating a snapshot. Typically, these ports are reserved for internal use by product owners or platform operators.
Through MCP, control ports can be exposed as tools to agents acting under defined roles or scopes. For instance, a domain-specific operational agent could monitor the performance and quality of a data product and autonomously decide to restart it in case of degradation, provided it has the necessary permissions and context. Similarly, agents could schedule or trigger data deletion routines in accordance with regulatory requirements.
This delegation of routine or reactive tasks to agents—when properly safeguarded—can reduce operational overhead and improve responsiveness without requiring full automation via deterministic workflows.
MCP's flexibility makes it applicable to a wide range of use cases, including those where systems are built on different stacks or standards but still need to interoperate seamlessly with agentic clients.
It is important to emphasize that MCP does not define what the tools do—only how they are exposed. The server implementer retains full control over the toolset, response semantics, and operational constraints. This flexibility is crucial in a heterogeneous environment where data products may differ widely in structure, purpose, and implementation details.
As such, organizations adopting MCP alongside data products must define internal conventions and schemas for tool description, parameter specification, and behavior modeling. This is similar in spirit to how REST or GraphQL interfaces require a shared understanding of semantics to ensure effective reuse.
If a data product already includes structured specifications for its interfaces—such as OpenAPI for output ports or custom domain models for control operations—these can be reused within the MCP framework, merely changing the communication protocol layer to match MCP expectations.
One of the recurring challenges in modern data architectures is interoperability at scale, especially in decentralized environments. The integration of agentic AI into enterprise systems introduces additional layers of complexity, as agents require reliable, consistent access to data and services, often across multiple domains and teams.
MCP provides a standardized, scalable way to address this challenge. Organizations implementing MCP can achieve enterprise-scale AI orchestration with MCP, enabling context-aware data quality assessment using LLMs while maintaining governance controls.
This also opens the door for data products to evolve beyond static producers of data. By participating in agentic workflows, they become active contributors to enterprise-wide intelligence, capable of interacting, responding, and adapting to the demands of automated reasoning systems.
The integration of MCP into data architectures represents a practical and forward-looking approach to enabling agent-based orchestration in the enterprise. It aligns with key principles of modularity, interoperability, and decentralization, while introducing minimal overhead in terms of implementation complexity.
As agentic systems mature and LLMs become more capable of autonomous reasoning and decision-making, the ability to interface (with data products especially) through standardized, semantically rich protocols will be increasingly critical.
Organizations that adopt MCP early will be better positioned to support this next wave of automation—where data, infrastructure, and AI systems are not merely connected but also capable of working together with context, awareness, and purpose.