Data integration platform company Nexla has been implementing native support for Model Context Protocol (MCP) as part of its wider efforts related to integration across its AI framework technologies. Company CTO Amey Desai explains that his firm’s work has gravitated around a mission to enable Nexla to convert any source into a “data product” with metadata, sample data, documentation and support for multiple protocols, including RESTful API support. So we might think we would just add MCP support as just another protocol right? Not so fast, let’s unravel the story.
Desai says that his team has already learned enough lessons about enterprise software realignment to know that embracing MCP (or supporting it within a product) requires a whole lot of thought and engineering. Nexla is a data integration platform that’s used for analytics, B2B, operations and for RAG pipelines in AI projects. The team argues that it is different from other data integration platforms in a few key ways that align closely with the principles of MCP.
Introspect inspection of data metadata
First, it abstracts data as data products. Just about any source, including any API, can be quickly turned into a logical data product called a Nexset. Nexla uses an LLM (currently AG2) to introspect data and metadata and then generate connectors and Nexsets that become the central access point for all data. They abstract away all differences among structured or unstructured data sources and decouple consumers and producers.
“Nexsets contain a number of artefacts, including metadata that represents the data schema, sample data, documentation, validation rules that are applied to data as it moves and protocol support,” said Desai. “Nexsets are also automatically accessible as RESTful APIs, but engineers use many other protocols and integration patterns with Nexsets, including ELT/ETL/R-ETL, streaming etc.”
Second, Nexla has a standardised way to discover and consume data and methods… and to add rules, which maps well to MCP resources, tools and prompts. Nexsets are all treated exactly the same way and can easily be published in a marketplace for broader discovery, consumption and governance. Third, Nexsets are designed to be used with an agentic framework. Users can use AI prompts to build any type of integration or flow, using Nexla’s agentic AI framework called NOVA. NOVA searches the underlying metadata of Nexsets to iteratively find the data and methods to invoke methods like transforms and perform prompt engineering as needed.
MCP, a USB-C for AI
As many will know, MCP has been called the USB-C port for AI applications. It’s a client-server architecture that specifies how MCP clients, such as AI applications or agents, connect to data sources via MCP Servers. Each MCP Server has resources (data), tools (functions) and prompts (to help improve LLM results.) Unlike RESTful APIs, MCP maintains context in each connection that supports an agentic “conversation” where a client can discover resources, tools and prompts and then decide how to use them.
But Desai points to MCP’s strengths and weaknesses, saying that the current MCP specification does have an elegant design with several strengths:
- Standardised AI Integration: MCP provides a standardised way for LLMs to discover and interact with data sources that’s designed for how LLMs work.
- Contextual Awareness: MCP helps AI agents understand the data, how it can use the data and some prompt engineering (referred to as resources, tools and prompts.)
- Real-time Interaction: With MCP, LLMs can dynamically query and iteratively (agentically) build out a flow or orchestration to answer a prompt.
- Self-Describing: MCP servers expose their capabilities through standardised schemas that LLMs can now understand.
But says Desai, MCP has several major challenges to overcome that will take time, something his team has learned from working with APIs. The biggest debate has, in fact, been why did MCP reinvent the wheel with a new protocol and not use RESTful APIs as its foundation? Here’s some of the why:
- Limited Ecosystem: It took a decade for RESTful APIs to become a de facto standard. It will be years before data will be directly available via MCP.
- Security Gaps: As noted in research, MCP hasn’t standardised authentication or authorisation to properly secure data usage by LLMs. Today it leaves the implementation details to the integration provider. We know from APIs that standards are needed.
- Error Handling: MCP doesn’t specify a standardised error-handling framework or response status codes – these are defined by each MCP implementer.
- Policy Management: MCP doesn’t provide a framework for implementing policies to help prevent attacks or govern data access via rate limiting and throttling. This also became standardized in the world of APIs.
- Network Chattiness: MCP can be chatty with all the discovery calls and network hops across MCP Servers to data sources. Over time, this should improve with various optimisations.
“If we learned anything from the world of APIs, it’s that APIs need to be secured and governed. Each API is an attack point for the outside world. APIs today are the biggest attack surface for most companies. This is why API gateways and all the standards around them exist,” explained Desai. “MCP today is even worse. It’s not just the more traditional API concerns because LLMs are also not completely secure either. Beyond data leaks, with MCP it’s even possible for a malicious MCP Server to hijack an LLM and access data in other MCP Servers in different scenarios (such as the confused deputy problem.)”
In short, he thinks that software engineers shouldn’t allow MCP Clients or Servers to directly access each other. Just like APIs, engineers need a proxy or gateway model.
Nexla’s Approach to MCP support
“After our own research and experimentation, we ended up with a few critical rules: treat an MCP Server as a fully governed data product (Nexset); expose non-MCP sources (Nexsets) as MCP Servers; support API Proxying to manage MCP requests across legacy APIs and systems; provide agentic orchestration to implement logic that combines MCP and non-MCP sources and handles all the format and protocol differences,” noted Desai. Exposing Nexla’s data products (Nexsets) through MCP allows AI agents to discover and query data sources using natural language, while maintaining the underlying data transformation and integration capabilities.”
Making use of Nexla’s existing API integration capabilities to translate between MCP requests and various backend systems (REST, GraphQL, databases, etc.) opens up the existing API and other ecosystems to MCP. Managing workflows that combine MCP-native interactions with traditional API calls helps implement the mappings, transforms and logic needed for end-to-end data flows across different formats and protocols.
Next MCP-steps
Looking ahead, Desai says that his team was able to extend its existing architecture to MCP and maintain compatibility with APIs and the rest of the non-MCP world because it had already built everything around data products and AI agents.
“As engineers are building out MCP support, perhaps the biggest lesson learned in hindsight is that any current architecture needs to be built for change. Data products insulate data sources from change. Supporting agents in the orchestration layer will protect teams from all the changes still happening with agentic AI,” concluded Desai. “Today, make sure you treat MCP like an API standard. Implement an MCP gateway pattern the same way you’d implement an API Gateway. Do not allow direct access without similar controls.”
Other software teams approaching this area should clearly think about making sure they future-proof their MCP architecture, especially when we remember that MCP (at the time of writing) is still an ever-evolving standard. As it changes, teams will need to make sure they insulate their own implementation to avoid major rework. Nexla decided to abstract MCP via data products and the orchestration flow type. Using the right gateway or proxy pattern should help other teams achieve a similar level of abstraction. We should now get ready for agent-to-agent interactions with standards like A2A. Don’t trust agents and agentic orchestration either. Orchestrations and agents also need to be governed.