MCP may be the most overused acronym in go-to-market technology right now. It is also one of the least clearly explained. The technical definition is Model Context Protocol: an open standard introduced by Anthropic in November 2024 for connecting AI applications to external data sources and tools. Instead of every AI application requiring a bespoke integration for every system it needs to access, MCP provides a common protocol through which compatible AI clients can discover and use external capabilities.
That sounds like an integration problem for developers. For GTM leaders, it could become something much more consequential. The important shift is not simply that ChatGPT, Claude or another assistant can retrieve information from a CRM. It is that AI systems are beginning to acquire a standard way to discover what business systems can do, understand which capabilities are relevant to a user's intent and invoke those capabilities as part of a wider task. Today, teams navigate between CRM, sales intelligence, enrichment, email, content, analytics and automation platforms. Tomorrow, the AI environment itself may increasingly become the place from which those systems are operated.
MCP is easier to understand as a standard plug
The cleanest analogy is the physical plug. Before electrical connectors were standardised, every appliance could theoretically have required a different connection to the wall. Standardisation separated the device from the connection mechanism. MCP attempts something similar for AI systems.
The protocol uses a host-client-server architecture. An AI application acts as the host, MCP clients maintain connections to MCP servers, and those servers expose capabilities such as resources, prompts and tools. Resources provide contextual information, tools perform actions and prompts package reusable interactions. The technical detail matters less than the architectural consequence: a vendor can expose its capabilities through one MCP server and multiple compatible AI environments can potentially connect to them without the vendor constructing a completely different integration for every assistant.
That is why the USB-C analogy appears so frequently. One standard connection does not make every device identical. It makes interoperability easier. The same principle applies here: MCP does not make Salesforce, Apollo or HubSpot the same product. It gives AI systems a more consistent way to understand and interact with what each platform exposes.
MCP does not replace the API
One of the most common misunderstandings is that MCP somehow supersedes APIs. It does not. APIs remain the underlying mechanism through which much software exposes data and actions, while MCP can sit above those capabilities and present them to AI systems in a more standardised and discoverable form.
The difference is best understood through the consumer. An API is primarily designed for software developers. The developer needs to know the endpoint, authentication mechanism, required parameters, expected schema and behaviour of the service, then write code that makes a deterministic request against that contract. MCP is designed for AI-oriented interaction. An MCP server can describe the tools and resources it exposes so an AI system can discover what is available and decide which capability is appropriate for the task. The underlying action may still result in an API call.
Think of the difference as completing a form. With an API, the developer knows which form is required and programmatically fills in the individual fields. With MCP, the user expresses the intent and the AI environment can identify the relevant tool and supply the required inputs. The form still exists. The interaction model around it changes.
GTM is where this starts becoming commercially interesting
Go-to-market technology is an unusually good environment in which to understand the implications because the modern GTM stack is fragmented by design. The CRM manages customer state. Sales intelligence platforms provide prospect data. Enrichment tools add information. Marketing platforms orchestrate campaigns. Email systems deliver messages. Analytics tools measure performance. Content lives somewhere else, and workflow automation connects parts of the estate together.
AI has so far largely followed the same pattern. Each vendor adds an assistant: the CRM gets an AI feature, the prospecting platform gets one, the email platform gets one and analytics gets another. The user still moves between applications. MCP creates the possibility of a different architecture: instead of embedding an isolated AI experience into every application, expose the applications as capabilities that an AI environment can orchestrate.
Apollo provides a useful example. Its MCP service allows compatible AI environments to search for prospects, enrich contacts, create or update records, add contacts to sequences and analyse campaign performance. Apollo remains the underlying system of record, but the conversational interface can become the place from which work is initiated. HubSpot follows a similar pattern through its remote MCP server, which allows compatible AI systems to interact with CRM data through authenticated connections. Salesforce is moving in the same direction with hosted MCP servers that can expose data, flows, Apex actions and other capabilities while retaining Salesforce permissions and governance.
This is no longer only a developer experiment. Major GTM platforms are beginning to make their capabilities agent-addressable.
The AI conversation can become an execution surface
Imagine a sales manager asking: Find 50 UK SaaS businesses with 100–500 employees that match our ICP, identify the heads of marketing, enrich the strongest 20 contacts, check whether any already exist in our CRM and prepare them for an outbound campaign.
That request crosses several traditional application boundaries. It involves prospect discovery, qualification, enrichment, deduplication, CRM access and potentially campaign execution. Historically, completing it requires a person to navigate multiple applications or an engineer to create a workflow joining them together.
MCP creates a third possibility. The AI system interprets the objective, discovers the available tools, invokes them in sequence and returns the result within the same working context. The significant change is not that any single capability is new. Prospect search, enrichment and CRM updates already exist. The change is that the user can potentially orchestrate those capabilities through intent rather than application navigation.
That distinction is strategically important. The system of record does not disappear. The interface to it moves.
The bigger shift is from applications to capabilities
For most of the SaaS era, the application has been the primary unit of enterprise software. Need customer data? Open Salesforce. Need prospects? Open Apollo. Need campaign performance? Open the analytics platform. Need an automation? Open the automation tool.
MCP starts to separate the capability from the interface. The CRM becomes less important as a screen and more important as the governed source of customer state, workflow logic and actions. Apollo becomes a prospecting and enrichment capability. Analytics becomes a measurement capability. Marketing automation becomes an activation capability. The AI environment becomes the layer that interprets the user's objective and coordinates those capabilities.
The application does not disappear. Its UI simply stops being the only way to use it. This is why MCP matters more than another AI feature. The GTM technology market has spent the past several years embedding generative AI inside individual products, but that does not solve fragmentation. A CRM assistant cannot orchestrate every external platform simply because it has a chat box. A prospecting assistant cannot understand the entire customer journey if it remains confined to the prospecting application.
MCP provides one piece of infrastructure for making those environments composable. OpenAI now supports MCP-powered apps that can allow ChatGPT to search connected systems and, where configured, perform write or modify actions such as updating records or triggering workflows. The strategic change is therefore not every GTM application gets AI. It is AI gains governed access to capabilities across the GTM estate.
Standardised connectivity is not autonomous GTM
This is where the excitement needs discipline. Standardised connectivity is not the same thing as reliable orchestration, and an MCP server exposing a tool does not mean an AI system should automatically be allowed to invoke it.
For GTM, the difference becomes practical very quickly. Reading campaign metrics is relatively low risk. Enriching a contact may consume paid credits. Creating thousands of CRM records could pollute a system of record. Enrolling prospects into an outbound sequence has commercial and reputational consequences. Deleting records or changing opportunity values could be materially damaging.
MCP standardises the connection. It does not determine the governance model. The strongest implementations will therefore combine probabilistic AI interpretation with deterministic controls around what actions can be taken, by whom, against which systems and under which conditions. Apollo's implementation illustrates this principle: its MCP service uses authenticated user permissions, applies existing credit controls and limits certain destructive actions. Salesforce follows the same underlying logic by keeping hosted MCP servers within its existing authentication and permissions model.
That is how enterprises should think about MCP. The protocol should not create a parallel permission universe for agents. Done correctly, it allows agents to operate through the identity and governance structures already surrounding the underlying business systems.
The GTM operating model could become conversational
There is a broader implication. Much of the current discussion assumes AI chat interfaces are simply more convenient ways to ask questions. That may underestimate what is changing. When the interface has access only to a model, it is conversational software. When it can retrieve organisational context, discover available capabilities and take governed actions across multiple systems, it begins to resemble an operating layer.
The user's request becomes the command. The AI provides interpretation. MCP exposes capabilities. Existing APIs perform the underlying transactions. Systems of record preserve authoritative state. Governance determines which actions are permitted.
That combination could create a very different GTM experience. Instead of opening six applications to investigate pipeline performance, a revenue leader asks why enterprise opportunities have slowed and requests the supporting evidence. Instead of manually building a prospect list, a salesperson describes the target account profile and asks the system to prepare a qualified segment. Instead of moving between CRM, email, enrichment and analytics, the GTM operator increasingly works from one AI environment that coordinates them.
The terminal, chat interface or AI workspace becomes less another tab in the GTM stack and more a control surface over the stack.
The interface may change faster than the systems underneath it
There is an important irony here: MCP could make established enterprise software more valuable, not less. If agents can operate HubSpot, Salesforce or Apollo without users constantly opening their interfaces, those platforms become infrastructure. Their data models, permissions, workflows and APIs matter enormously. Their screens matter slightly less.
That changes product strategy for GTM vendors. The question is no longer only, How do we add AI to our application? It becomes, How do we make our application useful to every authorised AI agent?
The companies that benefit may therefore not be those with the most impressive AI chat feature. They may be those with the best-governed, most useful capabilities for agents to discover and invoke.
MCP could become connective tissue, not the operating system
It is tempting to call MCP the operating system for agentic GTM. That goes too far. MCP does not reason. It does not define business strategy. It does not decide which prospect should be contacted or whether an opportunity should be advanced. It does not replace the CRM, the underlying APIs or the governance controls around them.
It is a protocol. But protocols can become enormously important when they remove friction between previously disconnected systems. HTTP did not create the web's content. SMTP did not write email. USB-C does not determine what a peripheral does. Their importance comes from standardising the connection.
That is the more useful way to think about MCP. If GTM vendors continue exposing their systems through a common agent-compatible standard, AI clients can become increasingly capable of working across the stack instead of being trapped inside individual applications. That could reduce integration effort, change the importance of user interfaces and move more GTM execution into natural-language environments.
The CRM remains. The sales intelligence platform remains. The marketing engine remains. But the human may increasingly stop operating each one directly.
The strategic question is no longer simply whether AI belongs inside the GTM stack. It is whether AI becomes the interface through which the GTM stack is operated — and whether MCP becomes one of the standards that makes that possible.
