If there’s been one perennial demand in martech, it’s integration.
In survey, after survey, after survey, ad nauseum, marketers consistently ranked martech integration as a top 3 challenge. Often their top issue. Maybe just below procuring more budget. (For some reason, there’s never enough budget.)
From the The State of the Marketing Operations Professional Trends for 2025 report by the MarketingOps community:
For martech platforms, this challenge was an opportunity.
If you were a martech platform that could attract enough other products to integrate with you, you could turn integration into a differentiated and monetizable feature.
Customers wanted integrations. You delivered them, out-of-the-box.
Salesforce was the OG example of this, with its AppExchange marketplace. Shopify and their App Store is another stellar example. I joined HubSpot in 2017 with the mission to create a similar ISV ecosystem — which has grown to over 1,900 integrations.
Integrations have been a legitimate moat for these platforms.
See, there were no standards for integration. Each platform defined its own interface for how other products had to integrate with it. Each integration a product wanted to have required time and resources to build and maintain. As a result, most products could only afford to integrate with a small number of platforms.
This created a flywheel dynamic. The more integrations a platform had, the more attractive it was to customers. The more customers on a platform, the more attractive it was for products to integrate with it.
Once a platform achieved critical mass with customers and integrations, new startups were often compelled to integrate with it in order to compete against incumbents in their category that were already integrated.
But after a few major platforms had established thriving ecosystems, it became harder for new platforms to enter the market. New startups had to integrate with the existing platforms first — that flywheel in action — and often lacked the time, resources, or customer demand to invest in newcomer platforms.
But what if there were a standard for integration?
The sudden, overnight rise of an integration standard
Last November, the AI company Anthropic introduced MCP, the Model Context Protocol. It’s all about context these days.
MCP was created to provide a standardized protocol for AI models, such as Anthropic’s Claude, to connect to data sources that could provide context in processing a task. For example, a customer service AI agent could dynamically pull in customer records from a CRM, tickets from a help desk, and documented solutions from a knowledge base to answer customer support questions.
MCP evolved out of Retrieval Augmented Generation, RAG, the technique of looking up data from a database and appending it to a prompt you’d feed into an LLM. But each RAG setup required its own bespoke implementation. There was no standard, and therefore no interoperability between different AI agents and data sources. We were still in the Dark Ages of fragmented integrations.
MCP is the dawn of the integration Enlightenment.
Of course, people propose standards all the time. (See XKCD.) Very few catch on because they lack mainstream adoption. MCP is remarkable because it was quickly embraced by Anthropic’s major rivals — Google, Microsoft, and OpenAI, who rarely agree on anything — as well as hundreds of other software companies.
In a mere 9 months, MCP has swept the software industry. It is a standard now.
How exactly does MCP work? It’s actually pretty simple. There are MCP servers and MCP clients. An MCP server is essentially just a wrapper around one or more APIs to retrieve data or execute functions. An MCP client is just a standardized way to connect with MCP servers.
Any MCP client can talk to any MCP server.
There are some nuances. An MCP client likely needs to be authenticated by an MCP server to access it. But most use OAuth for that, which is already a widely established standard. And while the connection between MCP clients and servers is standardized, what they each do via that connection is completely up to them.
You still need to find MCP servers, learn what they do, and get permission to use them. Ironically, there’s still a lot of context that you need to manage around the use of the Model Context Protocol. But a wave of MCP registries are emerging — such as smithery.ai — to help with this discovery.
But the big picture is this: implement an MCP server once, and any software — be it a new-fangled AI agent or an old-school SaaS app — that implements a MCP client can instantly integrate with it.
Launching a new platform? Expose its integration points via an MCP server and effectively every other software product in the cloud that has an MCP client can use it. They don’t have to build anything special for your platform to do that. Every MCP server automatically inherits integration with every MCP client. And vice versa.
MCP moves us from an world of integration scarcity to a world of integration abundance.
Strategic implications of abundant integration
So are platform ecosystems are no longer a moat?
At the lowest level of products being technically able to connect with each other, that is correct. There is no more moat at that level, just a massive pool that everyone can splash in.
But that former technical barrier was, frankly, a bit of a crutch that let software companies avoid thinking more deeply about what the true value of their ecosystem could or should be. The initial hurdle was a distraction from the real race that lay beyond.
Knocking down that first hurdle with MCP forces platforms and products to focus on more strategic dimensions of their ecosystems. And that’s a good thing for everyone.
To explain, I’ll refer to an article I published in 2019. Not all integrations are created equal: 4 layers of app integrations with SaaS platforms.
“Does X integrate with Y?” is a deceptively oversimplified yes/no question. In the cloud, the answer is almost always “yes.” It’s kind of like calling a restaurant and asking if they combine ingredients together. Sure they do. But how tasty is the meal? How attentive is the service? How reasonable is the price?
I developed a 2-dimensional framework to evaluate integrations on four layers (the y-axis):
Data: passing fields, records, or other packets of information between systems. This is the most common kind of integration between cloud services.
Process (Workflow): standardizing or automating the flow of data and activity between people and systems. The most common pattern is an event in one system triggering a sequence of predetermined actions across others.
User Interface: embedding elements of the integrated app — or the entire app itself — in the user interface/user experience of the platform. This gives platform users visibility into and the ability to interact with integrated apps, without continually switching between different systems and interfaces.
Governance: establishing and enforcing rules and standards across all approved apps in the platform’s ecosystem. This makes it easier and safer for users to adopt and manage apps built by different vendors with greater consistency and control.
Within each of these layers, integrations may be relatively shallow and lightweight, with very limited capabilities or use cases, or rich and deep, delivering more capabilities and serving more advanced use cases (the x-axis):
Now, with MCP, shallow integration become automatically available and commoditized. An additional standard proposed by Google, Agent2Agent (A2A), aims to further standardize more integration dynamics, which I’ve approximated here:
The net effect: shallow integrations are no longer a moat.
Ecosystems > Integrations
The post MCP is making integration universally abundant, which ironically makes ecosystems even more strategic appeared first on chiefmartec.