Your sales lead asks an AI assistant which deals slipped this quarter, and it answers from a spreadsheet someone exported on Monday. Your operations manager wants an agent to update order status in NetSuite, and IT asks who will build the connector, who will maintain it, and what the agent will be allowed to change. Somewhere in that conversation, a new acronym turns up: MCP.
The short answer to MCP vs API is that MCP does not replace your APIs. It sits on top of them. An API is how one system talks to another; the Model Context Protocol is a standard way of describing what a system can do, so that any AI agent can find those capabilities and use them. To connect AI agents to a CRM or ERP, start with the MCP server your vendor already ships, build on the API where it falls short, and keep your iPaaS where it already runs your integrations. This guide explains how the three fit together, what the MCP servers from Salesforce, HubSpot, NetSuite, and SAP actually allow, and how to let an agent write to your records without breaking them.
- MCP is a layer over APIs: an MCP server usually calls the same APIs your integrations already use.
- Salesforce, HubSpot, and NetSuite now ship their own MCP servers, and each one runs with the permissions of the person who connects it.
- An agent that can write to a CRM or ERP needs narrow tools, approval for consequential changes, and a log of every action, whichever connection method it uses.
- MCP and RAG do different jobs: RAG answers from documents; MCP lets an agent query and act in live systems.
MCP vs API: The Short Answer
An API is written for developers. It publishes endpoints, and a developer writes code that calls them in a fixed order for a known purpose. An AI agent can use an API only through code someone wrote for that agent: a function definition, an authentication flow, and error handling, rebuilt for each AI tool you adopt.
MCP is written for AI clients. An MCP server describes its tools, the data it can return, and the inputs each tool needs, in a format any MCP-compatible client can read at runtime: Claude, ChatGPT, Microsoft Copilot Studio, coding assistants, and agent frameworks. Connect the server once, and every compatible client can discover what it offers. Anthropic introduced MCP as an open standard in November 2024, and in December 2025 it was moved to the Agentic AI Foundation under the Linux Foundation.
MCP vs API Example: One Task, Two Ways
Take one request: move a HubSpot deal to the next stage. Through the API, a developer writes code that signs in, finds the deal, looks up the stage IDs the pipeline uses, and sends the update; the assistant can only trigger that code. Through MCP, an agent connected to the HubSpot MCP server reads the list of tools the server offers, picks the one that updates a deal, and calls it with the deal and the new stage. The server makes the same API call underneath, as the person who connected it.
Why Not Let the Model Call the API Directly?
A capable model can read an API’s documentation or its OpenAPI specification and write the calls itself, and for one developer trying something out, that works. In a business system, the work that matters sits around the call: signing in as the right person, refusing actions that person is not allowed to take, staying within rate limits, and returning errors the agent can act on. An MCP server does that once, in tested code, instead of leaving every agent to improvise it on every request.
What MCP Adds on Top of an API, and What It Doesn’t
Inside, an MCP server offers three kinds of building blocks, defined in the MCP specification. Tools are actions the agent can call, such as looking up an account or creating a ticket. Resources are read-only data, such as a record or a database schema, that the application passes to the model as context. Prompts are ready-made instructions a user picks to start a task. A server runs either locally, on the same machine as the AI client, or remotely over HTTP, where it serves many users and the protocol recommends OAuth for sign-in.
One point that many comparisons still get wrong: MCP is not a stateful protocol. Since the 2026-07-28 version of the protocol, every request carries the protocol version and the capabilities the server needs, so the server handles each request on its own, much as a REST API does. Descriptions of MCP as stateful and APIs as stateless refer to earlier versions.
MCP removes repeated work. Without it, every AI tool your company adopts needs its own connector to each system. With it, the connector is built once, as an MCP server, and the AI tools change around it. It also standardizes how an agent signs in: remote MCP servers use OAuth, so the agent acts as a specific person.
How the tools are designed matters more than how many there are. Every tool a server exposes is described to the model, and those descriptions take up the context the model reasons in, so a server that mirrors every API endpoint hands the agent a long list to choose from and more ways to choose wrong. Servers that work well expose a smaller set of tools at the level of a business action, such as “update order status,” and make the endpoint calls behind each one.
What MCP does not fix is everything underneath. If your CRM is full of duplicate accounts, an agent reads duplicates faster. If an API is rate-limited, the MCP server inherits the limit. If the business rule that decides whether an order can be changed lives in someone’s head, no protocol will find it. And if a legacy ERP has no usable API at all, there is nothing for an MCP server to wrap until someone builds one. That is why the connection question is usually the smaller half of an AI CRM integration project; the data and the rules take longer.
Where iPaaS Fits
Many mid-size companies already run their integrations through an iPaaS such as MuleSoft, Workato, or Boomi, and those platforms are adding MCP support. Check what it exposes before planning around it: an MCP server for managing the integration platform is not the same as one that turns your integrations into agent tools.
If your integrations already live in an iPaaS, start there: the error handling, retries, and monitoring your team built for those flows come along. If they do not, an iPaaS is rarely worth buying just to reach MCP, because the CRM and ERP vendors now ship MCP servers of their own.
MCP Servers Your CRM and ERP Already Ship
Before anyone builds a custom server, check what the vendor provides. Here is what four common platforms offer, as their own documentation described it when we checked in November 2026.
Salesforce MCP
Salesforce MCP support comes as Salesforce Hosted MCP Servers, Salesforce’s generally available implementation of the standard. The tools run with the permissions of the user who authenticated, and field-level security, object permissions, and sharing rules apply to every tool call. Some of the standard servers are still in beta, and hosted servers are intended for customers with Flex Credits, with usage that may be billed, so check both before planning around one. Where the standard servers stop, Salesforce lets you create custom servers alongside them; building one is Salesforce development work, with the same testing and permission review as any custom integration.
HubSpot MCP Server
The remote HubSpot MCP server became generally available to all HubSpot accounts on 13 April 2026. It reads CRM records, marketing content, and activities, and it can create and update contacts, companies, deals, tickets, line items, products, and activities. Quotes, invoices, and orders stay read-only. Connections use OAuth 2.1 with PKCE, and every action respects the user’s existing HubSpot permissions. If an account has sensitive data turned on, activities are blocked from the server altogether.
NetSuite MCP
Oracle connects NetSuite to AI clients through the NetSuite AI Connector Service, which runs on MCP. Access follows NetSuite role permissions. The MCP Standard Tools SuiteApp lets an agent create, read, and update records, run reports and saved searches, and query with SuiteQL, which is read-only. The service itself is not a paid feature, although the AI client you connect may be.
SAP MCP Server
SAP’s support is spread across products rather than one server. Agents built in Joule Studio support MCP and Agent2Agent, and SAP Integration Suite includes an MCP Gateway that exposes existing APIs and integration flows as MCP tools. SAP’s reference architecture describes how third-party MCP servers reach SAP systems on BTP. For most SAP customers, that means the route to MCP runs through the integration layer they already have. Setting up that route is part of our SAP consulting services.
What an Agent Is Allowed to See
Every vendor server above makes the same design choice: the agent acts as the person who connected it, not as a shared service account. That is the right default, and it is worth keeping when you build your own connections. An integration account with broad access, wired to an AI assistant, gives every employee who can talk to the assistant the access of that account.
The same principle applies to retrieval. An assistant that answers from company documents should see only what the person asking is allowed to see. For a UK IT services company, we built a retrieval platform on AWS that searches across SharePoint, Salesforce, and S3 in one place, and it brought 60% faster work with company documents. The platform keeps the index in step with each source system and applies each user’s access rights to every answer. That, not the search, is the hard part of a project like this.
MCP security also has a protocol-level side: what each tool is allowed to do, what inputs it accepts, and how a prompt injected into a document or an email could steer an agent into calling a tool it should not. Those risks belong in the same review as any other system with write access.
Letting an Agent Write Back Without Breaking Records
Reading is the easy part. The question every CRM and ERP owner asks is what happens when the agent writes. The vendors’ own choices point to the answer: start narrow and widen access one step at a time.
- Read-only first. The agent answers questions and drafts changes as suggestions. People see what it would do before it does anything.
- Narrow write tools. Instead of one tool that can update any field, give the agent tools for specific actions: log a call, move a deal stage, create a ticket.
- Approval for consequential changes. Anything above an agreed threshold, such as a price, a credit limit, or a deletion, goes to a person.
- Safe retries. A write that is retried after a timeout must not create a second record. Each action carries a key that makes repeats harmless.
- A log of every action. What the agent read, what it changed, and on whose behalf.
- A way back. The previous value is stored, so a wrong change can be reversed without restoring a backup.
For a US construction contractor, our email AI agent sorts incoming documents and files them in Procore and SharePoint, and it made document ingestion 70–80% faster. The pattern above is what lets an agent like that write into systems a business depends on, and it belongs in the first release of any AI agent, not in a fix after the first wrong write.
MCP vs RAG: Different Jobs
MCP vs RAG is not a choice between alternatives. Retrieval-augmented generation finds the right passages in your documents and gives them to the model, so it can answer from your knowledge rather than from its training. MCP gives an agent access to live systems, so it can look up a record as it stands now and act on it.
A sales assistant shows the difference. “What is our standard discount policy for renewals?” is a RAG question: the answer sits in a policy document. “Which of my renewals this month are above that discount?” is an MCP question: the answer lives in the CRM. Most useful assistants need both, and both depend on the same groundwork: pipelines that keep sources current, which is the data engineering underneath any AI that answers from company data.
When to Use MCP, an API, or an iPaaS
Legacy ERP With No Usable API
Older ERPs are the hardest case. If the system exposes a database but no API, the safer route is a read replica or a small API layer in front of it, with write operations going through a queue that the ERP’s own logic processes. That layer can then be wrapped as an MCP server like any other. Screen automation through RPA is the last resort: it works, but it breaks whenever the interface changes. Where the system itself is the bottleneck, legacy software modernization can cost less over time than keeping a wrapper alive around it, so compare the two before committing to either.
How Crunch-IS Connects AI Agents to CRM and ERP
Most of the work in connecting AI agents to a CRM or ERP sits below the protocol. Our AI CRM integration services start with a review of the data model, duplicate and missing records, field usage, and access rights. The agents we then build run under a scoped CRM user, apply each person’s access rights, and log every change, so any update can be traced and reversed. They begin by proposing updates for a person to approve, and a step runs on its own only once its error rate is low enough.
On the ERP side, the groundwork is often an API layer that does not exist yet. For a UK energy equipment company whose business lines ran on Microsoft Dynamics 365, SAP Business One, and spreadsheets, we built a central API layer and a data platform that synchronizes all of them in real time: the foundation an agent, or an MCP server, needs underneath it. Our ERP development services cover the same work for SAP, NetSuite, and Odoo.
MCP is also part of how we deliver. On a SAP-integrated manufacturing app built by an AI Pod, the team ran its engineering workflow on MCP, reusable prompt libraries, and specialized subagents, and shipped the MVP 63% faster with a 56% smaller delivery team.
Conclusion
The MCP vs API question has a simpler answer than the acronyms suggest. MCP is the layer that lets any AI agent find and use what your systems can do; the APIs underneath still do the work. Start with the MCP server your CRM or ERP vendor ships, add a custom server on top of the API where the agent needs logic the vendor does not expose, and keep the iPaaS that already runs your integrations.
The connection is rarely what holds a project back. Clean records, business rules someone has written down, and write access that widens one step at a time decide whether an agent can be trusted inside your CRM and ERP, and all three are worth settling before the first agent goes live.
