Artificial Intelligence is no longer experimental. It is embedded in our daily workflows, communication, research, and increasingly, in investment processes. In Private Markets, the impact is visible: SaaS vendors are rapidly integrating AI capabilities into their platforms, primarily through chat interfaces, copilots, and task-oriented agents that promise efficiency gains across deal sourcing, due diligence, portfolio monitoring, and reporting.
Some implementations deliver incremental value. Others feel more like feature inflation than transformation.
Current concerns and challenges
While AI-enhanced SaaS tools offer convenience, they also introduce concerns:
- Black box outputs – What model is being used? How are outputs generated? Can decisions be traced, audited or explained?
- Model dependency – Are you locked into a single vendor’s chosen LLM? Can you switch models based on performance, cost, or compliance requirements?
- Security and privacy beyond the SaaS perimeter – Where is your data processed? Is it retained? Is it used for model training? How does it interact with other tenants?
For institutions managing sensitive financial data, LP communications, and proprietary deal intelligence, these are not academic concerns – they are governance, regulatory, and fiduciary issues.
This is where a new architectural concept enters the conversation: MCP.
MCP: a structural shift in AI integration
MCP (Model Context Protocol) is not another AI feature layered into an application. It is an open standard that standardises how AI applications connect to external data sources and tools. It was originally released by Anthropic in late 2024 and is now supported across the major AI platforms (Anthropic, Google, Microsoft, OpenAI) and a growing ecosystem of community-built servers.
Rather than embedding proprietary integrations inside each SaaS product, MCP creates a structured, permissioned way for AI systems to retrieve context from (and act on) data within your systems.
Let’s break it down into its core components:
The host is the AI-enabled application where users interact with the model: Claude Desktop, Copilot, ChatGPT, or a custom internal AI workspace. In practice, most firms will standardise around one primary host, which becomes the official AI interface for employees. The host orchestrates requests, manages user interaction, and determines when external context is required.
Clients are components within the host that establish and maintain a connection to each MCP server. Each client has a one-to-one relationship with a single server, mediating all communication between the host and that server. They send requests to MCP servers, they retrieve structured data, and they pass that data back to the model for reasoning.
The host does not directly access external systems; the model does not directly query databases. Clients sit between them.
MCP servers expose specific systems in a standardised format. Each server typically represents a system or domain: CRM, deal pipeline, data warehouse, document repository, and defines what is available, how it can be accessed, and enforces authentication and authorisation. Servers expose three types of primitives:
- Tools – actions the model can take (run a query, update a CRM record, generate a report).
- Resources – data the model can read (documents, datasets, records).
- Prompts – reusable templates that guide repeatable workflows.
This distinction matters. MCP doesn’t just let a model read your data, it lets it act on your systems too, through the same governed protocol. That’s the difference between an AI that can summarise and an AI that can do. Think of MCP as a USB-C for AI: any compliant host can plug into any compliant data source or tool, without bespoke integration code on either side, the protocol takes care of how they talk to each other.
Data is not embedded into the model. It is retrieved or acted upon at inference time through a governed protocol layer. Whether that data is logged or retained beyond inference depends on the host and LLM provider’s deployment terms, which firms should review and contractually constrain. Governance ultimately depends on deployment architecture and contractual controls, not on MCP alone.
Why this matters in Private Markets?
Private Markets firms differentiate themselves through:
- Proprietary deal flow.
- Investment strategy.
- Historical performance data.
- LP relationships.
With an MCP-style architecture, this intelligence does not sit inside a single SaaS vendor’s AI layer. The architecture decouples the AI interface (the host, where users interact with AI) from data ownership (the systems behind each MCP server, where your firm’s data lives).
This separation matters in practice. Imagine a deal partner asking the firm’s AI Agent: “Show me prior deals in industrial services where management changed within twelve months of acquisition, the IC theses for each, and how performance tracked against the original underwriting.” In a world where AI is embedded inside individual SaaS platforms, that question can only be answered if all data required to answer that question lives inside that single SaaS product, which it never does. With MCP, the host queries the deal system, the document repository (for the IC papers), and the portfolio monitoring system (for performance data) and synthesises an answer grounded from the firm’s actual systems.
Practically, this gives the firm:
- The ability to stay flexible without rewriting integrations.
- The ability to add or swap AI models without migrating data.
- The ability to expose new systems to AI without locking into a single vendor.
- A foundation for consistent AI governance patterns across tools, provided each MCP server enforces them (MCP is the plumbing, not the governance framework itself).
The shift away from per-vendor custom integrations is also a real engineering economy:
The savings compound as both the number of hosts and the number of systems grow, and they let firms add new AI capabilities or retire old systems without rewiring everything else.
It is not about replacing SaaS tomorrow. It is about structuring your systems so that any compliant AI host can securely and intelligently access your firm’s knowledge.
What this means for SaaS
The natural next question is what happens to the SaaS layer when MCP and generative interfaces mature. The honest answer is that the role of SaaS will likely change, not disappear, and can be significant.
When firm data lives in a governed layer (warehouse for structured data, document repository for unstructured) and is exposed through MCP, an AI host can retrieve it and act on it directly. When that same host can also generate interfaces on demand think a deal screening view, a portfolio dashboard or an IC paper draft – the proprietary UI that many SaaS platforms charge for becomes optional.
Consider the following example: A partner asks the firm’s AI Agent: “Show me revenue growth for our healthcare portfolio companies over the last three quarters, indexed to entry, with the outliers highlighted.” The host queries the data sources via MCP, retrieves the underlying figures, and generates a chart and short commentary directly in the conversation. No BI licence, no pre-built report, no analyst, no meeting. The workflow that used to involve three tools and two people collapses into one prompt.
The likely outcome: SaaS whose value is genuinely specialised in areas such as fund accounting, complex analytics or regulatory-grade systems of record will need to feed the AI layer as a service rather than traditional user-facing applications. SaaS whose moat was really “we built the interface and integrated your data” faces a harder question. The interface and the integration are exactly what MCP and generative AI compress.
Is MCP just another buzzword?
It could be if reduced to marketing language. But conceptually, MCP reflects a broader shift in how firms should think about AI. Instead of asking: “Which AI tool or SaaS platform should we buy?”, the question becomes: “How do we expose our knowledge in a structured, governed way so that any compliant AI system can reason over it?”
That shift requires:
- Clean internal data architecture.
- Defined permission models.
- Documentation of systems.
- Governance maturity.
Not every firm is ready to move fully in that direction, which means SaaS platforms will continue to play a central role in the broader data architecture. The PE firms best positioned for what comes next are the ones investing in the layer beneath MCP servers: clean data, well-defined permissions, and clear system roles. When the right use case emerges, the MCP layer should enable a small, targeted piece of work: not become a foundational rebuild.
The real competitive edge
AI models will improve. SaaS platforms will continue to multiply. New hosts will emerge. What remains durable is:
- Your proprietary data.
- Your institutional knowledge.
- Your investment judgment.
- Your internal processes.
MCP does not create competitive advantage by itself. What it does is ensure that your competitive assets can be accessed intelligently by any compliant AI system, without surrendering control.
In a world where AI is available to everyone, the edge will not come from the tool. It will come from how well your knowledge is structured, governed, and accessed.
That is a design choice, not a product decision.
Ready to prepare your firm for what’s next?
Whether you’re exploring AI copilots today or evaluating how emerging standards like MCP fit into your long-term technology strategy, success starts with the right foundations. Learn how our AI Readiness service helps private markets firms build the data, governance and technology capabilities needed to adopt AI securely and at scale.
