Din säljchef frågar en AI-assistent vilka affärer som har halkat efter det här kvartalet, och den svarar utifrån ett kalkylark som någon exporterade i måndags. Din driftchef vill att en agent ska uppdatera orderstatus i NetSuite, och IT frågar vem som ska bygga kopplingen, vem som ska underhålla den och vad agenten ska få ändra. Någonstans i det samtalet dyker en ny förkortning upp: MCP.
Det korta svaret på frågan MCP vs API är att MCP inte ersätter dina API:er. Det ligger ovanpå dem. Ett API är sättet som ett system pratar med ett annat på; Model Context Protocol är ett standardiserat sätt att beskriva vad ett system kan göra, så att vilken AI-agent som helst kan hitta de funktionerna och använda dem. För att koppla AI-agenter till ett CRM eller ERP börjar du med den MCP-server som din leverantör redan levererar, bygger på API:et där den inte räcker till och behåller din iPaaS där den redan kör dina integrationer. Den här guiden förklarar hur de tre hänger ihop, vad MCP-servrarna från Salesforce, HubSpot, NetSuite och SAP faktiskt tillåter och hur du låter en agent skriva till dina poster utan att förstöra dem.
- MCP är ett lager ovanpå API:er: en MCP-server anropar oftast samma API:er som dina integrationer redan använder.
- Salesforce, HubSpot och NetSuite levererar nu egna MCP-servrar, och var och en av dem körs med behörigheterna hos den person som ansluter den.
- En agent som kan skriva till ett CRM eller ERP behöver smala verktyg, godkännande för ändringar med konsekvenser och en logg över varje åtgärd, oavsett vilken anslutningsmetod den använder.
- MCP och RAG gör olika jobb: RAG svarar utifrån dokument; MCP låter en agent ställa frågor till och agera i levande system.
MCP vs API: det korta svaret
Ett API är skrivet för utvecklare. Det publicerar endpoints, och en utvecklare skriver kod som anropar dem i en fast ordning för ett känt syfte. En AI-agent kan bara använda ett API genom kod som någon har skrivit för just den agenten: en funktionsdefinition, ett autentiseringsflöde och felhantering, som byggs om för varje AI-verktyg du inför.
MCP är skrivet för AI-klienter. En MCP-server beskriver sina verktyg, vilka data den kan returnera och vilka indata varje verktyg behöver, i ett format som alla MCP-kompatibla klienter kan läsa vid körning: Claude, ChatGPT, Microsoft Copilot Studio, kodassistenter och agentramverk. Anslut servern en gång, så kan varje kompatibel klient upptäcka vad den erbjuder. Anthropic lanserade MCP som en öppen standard i november 2024, och i december 2025 flyttades det till Agentic AI Foundation under Linux Foundation.
Exempel på MCP vs API: en uppgift, två sätt
Ta en enda begäran: flytta en affär i HubSpot till nästa steg. Via API:et skriver en utvecklare kod som loggar in, hittar affären, slår upp vilka steg-ID:n pipelinen använder och skickar uppdateringen; assistenten kan bara utlösa den koden. Via MCP läser en agent som är ansluten till HubSpots MCP-server listan över verktyg som servern erbjuder, väljer det som uppdaterar en affär och anropar det med affären och det nya steget. Servern gör samma API-anrop under ytan, som den person som anslöt den.
Varför inte låta modellen anropa API:et direkt?
En kapabel modell kan läsa ett API:s dokumentation eller dess OpenAPI-specifikation och skriva anropen själv, och för en utvecklare som testar något fungerar det. I ett affärssystem är det arbetet runt anropet som räknas: att logga in som rätt person, vägra åtgärder som den personen inte får utföra, hålla sig inom gränserna för antalet anrop och returnera fel som agenten kan agera på. En MCP-server gör det en gång, i testad kod, i stället för att låta varje agent improvisera fram det vid varje begäran.
Vad MCP lägger till ovanpå ett API, och vad det inte gör
Inuti erbjuder en MCP-server tre typer av byggstenar, som definieras i MCP-specifikationen. Verktyg är åtgärder som agenten kan anropa, till exempel att slå upp ett konto eller skapa ett ärende. Resurser är skrivskyddade data, till exempel en post eller ett databasschema, som applikationen skickar till modellen som kontext. Prompter är färdiga instruktioner som en användare väljer för att starta en uppgift. En server körs antingen lokalt, på samma maskin som AI-klienten, eller på distans över HTTP, där den betjänar många användare och protokollet rekommenderar OAuth för inloggning.
En punkt som många jämförelser fortfarande får fel: MCP är inte ett tillståndsbaserat protokoll. Sedan protokollversionen 2026-07-28 bär varje begäran med sig protokollversionen och de funktioner som servern behöver, så att servern hanterar varje begäran för sig, ungefär som ett REST API gör. Beskrivningar av MCP som tillståndsbaserat och API:er som tillståndslösa gäller tidigare versioner.
MCP tar bort upprepat arbete. Utan det behöver varje AI-verktyg som ditt företag inför en egen koppling till varje system. Med det byggs kopplingen en gång, som en MCP-server, och AI-verktygen kan bytas ut runt den. Det standardiserar också hur en agent loggar in: MCP-fjärrservrar använder OAuth, så agenten agerar som en specifik person.
Hur verktygen är utformade spelar större roll än hur många de är. Varje verktyg som en server exponerar beskrivs för modellen, och de beskrivningarna tar upp det kontextutrymme som modellen resonerar i. En server som speglar varje API-endpoint ger därför agenten en lång lista att välja från och fler sätt att välja fel. Servrar som fungerar bra exponerar en mindre uppsättning verktyg på nivån av en affärsåtgärd, till exempel ”uppdatera orderstatus”, och gör endpoint-anropen bakom vart och ett av dem.
Det som MCP inte löser är allt som ligger under. Om ditt CRM är fullt av dubblettkonton läser en agent dubbletter snabbare. Om ett API har en gräns för antalet anrop ärver MCP-servern den gränsen. Om affärsregeln som avgör om en order får ändras bara finns i någons huvud kommer inget protokoll att hitta den. Och om ett äldre ERP inte har något användbart API alls finns det inget för en MCP-server att kapsla in förrän någon bygger ett. Därför är anslutningsfrågan oftast den mindre halvan av ett projekt för AI-integration i CRM; data och regler tar längre tid.
Där iPaaS passar in
Många medelstora företag kör redan sina integrationer via en iPaaS som MuleSoft, Workato eller Boomi, och de plattformarna lägger nu till stöd för MCP. Kontrollera vad den exponerar innan du planerar utifrån den: en MCP-server för att hantera själva integrationsplattformen är inte samma sak som en som gör dina integrationer till verktyg för agenter.
Om dina integrationer redan finns i en iPaaS, börja där: felhanteringen, omförsöken och övervakningen som ditt team har byggt för de flödena följer med. Om de inte gör det är en iPaaS sällan värd att köpa bara för att nå MCP, eftersom CRM- och ERP-leverantörerna nu levererar egna MCP-servrar.
MCP-servrar som ditt CRM och ERP redan levererar
Innan någon bygger en egen server bör du kontrollera vad leverantören erbjuder. Så här ser det ut hos fyra vanliga plattformar, enligt deras egen dokumentation när vi kontrollerade i november 2026.
Salesforce MCP
Stödet för MCP i Salesforce kommer i form av Salesforce Hosted MCP Servers, Salesforces allmänt tillgängliga implementering av standarden. Verktygen körs med behörigheterna hos den användare som autentiserade sig, och säkerhet på fältnivå, objektbehörigheter och delningsregler gäller för varje verktygsanrop. Vissa av standardservrarna är fortfarande i beta, och de hostade servrarna är avsedda för kunder med Flex Credits, med användning som kan debiteras, så kontrollera båda delarna innan du planerar utifrån en av dem. Där standardservrarna inte räcker låter Salesforce dig skapa egna servrar vid sidan av dem; att bygga en sådan är Salesforce-utveckling, med samma testning och behörighetsgranskning som vilken anpassad integration som helst.
HubSpots MCP-server
HubSpots MCP-fjärrserver blev allmänt tillgänglig för alla HubSpot-konton den 13 april 2026. Den läser CRM-poster, marknadsföringsinnehåll och aktiviteter, och den kan skapa och uppdatera kontakter, företag, affärer, ärenden, orderrader, produkter och aktiviteter. Offerter, fakturor och order förblir skrivskyddade. Anslutningar använder OAuth 2.1 med PKCE, och varje åtgärd respekterar användarens befintliga behörigheter i HubSpot. Om ett konto har funktionen för känsliga data aktiverad blockeras aktiviteter helt från servern.
NetSuite MCP
Oracle ansluter NetSuite till AI-klienter via NetSuite AI Connector Service, som körs på MCP. Åtkomsten följer rollbehörigheterna i NetSuite. Med MCP Standard Tools SuiteApp kan en agent skapa, läsa och uppdatera poster, köra rapporter och sparade sökningar och ställa frågor med SuiteQL, som är skrivskyddat. Själva tjänsten kostar inget extra, även om AI-klienten du ansluter kan göra det.
SAP:s MCP-server
SAP:s stöd är utspritt över flera produkter i stället för en enda server. Agenter som byggs i Joule Studio stöder MCP och Agent2Agent, och SAP Integration Suite innehåller en MCP Gateway som exponerar befintliga API:er och integrationsflöden som MCP-verktyg. SAP:s referensarkitektur beskriver hur MCP-servrar från tredje part når SAP-system på BTP. För de flesta SAP-kunder innebär det att vägen till MCP går genom det integrationslager de redan har. Att sätta upp den vägen ingår i våra konsulttjänster för SAP.
Vad en agent får se
Varje leverantörsserver ovan gör samma designval: agenten agerar som den person som anslöt den, inte som ett delat tjänstekonto. Det är rätt standardval, och det är värt att behålla när du bygger egna anslutningar. Ett integrationskonto med bred åtkomst som kopplas till en AI-assistent ger varje anställd som kan prata med assistenten samma åtkomst som det kontot har.
Samma princip gäller för informationshämtning. En assistent som svarar utifrån företagets dokument ska bara se det som personen som frågar har rätt att se. För ett IT-tjänsteföretag i Storbritannien byggde vi en plattform för informationshämtning på AWS som söker i SharePoint, Salesforce och S3 på ett och samma ställe, och den gav 60 % snabbare arbete med företagets dokument. Plattformen håller indexet i takt med varje källsystem och tillämpar varje användares behörigheter på varje svar. Det, och inte sökningen, är den svåra delen av ett sådant projekt.
MCP-säkerhet har också en sida på protokollnivå: vad varje verktyg får göra, vilka indata det accepterar och hur en prompt som har injicerats i ett dokument eller ett mejl kan styra en agent till att anropa ett verktyg som den inte borde anropa. De riskerna hör hemma i samma granskning som alla andra system med skrivåtkomst.
Låt en agent skriva tillbaka utan att förstöra poster
Att läsa är den enkla delen. Frågan som varje ägare av ett CRM eller ERP ställer är vad som händer när agenten skriver. Leverantörernas egna val pekar mot svaret: börja smalt och utöka åtkomsten ett steg i taget.
- Skrivskyddat först. Agenten besvarar frågor och tar fram ändringar som förslag. Människor ser vad den skulle göra innan den gör något.
- Smala skrivverktyg. I stället för ett verktyg som kan uppdatera vilket fält som helst ger du agenten verktyg för specifika åtgärder: logga ett samtal, flytta en affär till ett nytt steg, skapa ett ärende.
- Godkännande för ändringar med konsekvenser. Allt över en överenskommen tröskel, till exempel ett pris, en kreditgräns eller en radering, går till en person.
- Säkra omförsök. En skrivning som görs om efter en timeout får inte skapa en andra post. Varje åtgärd har en nyckel som gör upprepningar ofarliga.
- En logg över varje åtgärd. Vad agenten läste, vad den ändrade och för vems räkning.
- En väg tillbaka. Det tidigare värdet sparas, så att en felaktig ändring kan återställas utan att man behöver läsa tillbaka en säkerhetskopia.
För en byggentreprenör i USA sorterar vår AI-agent för e-post inkommande dokument och arkiverar dem i Procore och SharePoint, och den gjorde dokumentmottagningen 70–80 % snabbare. Mönstret ovan är det som gör att en sådan agent kan skriva in i system som ett företag är beroende av, och det hör hemma i den första versionen av varje AI-agent, inte i en rättning efter den första felaktiga skrivningen.
MCP vs RAG: olika jobb
MCP vs RAG är inte ett val mellan alternativ. RAG (hämtningsförstärkt generering) hittar rätt avsnitt i dina dokument och ger dem till modellen, så att den kan svara utifrån din egen kunskap i stället för utifrån sin träning. MCP ger en agent åtkomst till levande system, så att den kan slå upp en post som den ser ut just nu och agera på den.
En säljassistent visar skillnaden. ”Vilken är vår standardpolicy för rabatter vid förnyelser?” är en RAG-fråga: svaret finns i ett policydokument. ”Vilka av mina förnyelser den här månaden ligger över den rabatten?” är en MCP-fråga: svaret finns i CRM:et. De flesta användbara assistenter behöver båda, och båda bygger på samma grundarbete: pipelines som håller källorna aktuella, vilket är den datateknik som ligger under all AI som svarar utifrån företagsdata.
När du ska använda MCP, ett API eller en iPaaS
Äldre ERP utan användbart API
Äldre ERP-system är det svåraste fallet. Om systemet exponerar en databas men inget API är den säkrare vägen en läsreplik eller ett litet API-lager framför den, där skrivoperationer går via en kö som ERP-systemets egen logik bearbetar. Det lagret kan sedan kapslas in som en MCP-server precis som vilket annat som helst. Skärmautomatisering via RPA är sista utvägen: det fungerar, men det går sönder varje gång gränssnittet ändras. Där själva systemet är flaskhalsen kan modernisering av äldre programvara kosta mindre över tid än att hålla liv i ett skal runt det, så jämför de två alternativen innan du bestämmer dig för något av dem.
Så kopplar Crunch-IS AI-agenter till CRM och ERP
Det mesta av arbetet med att koppla AI-agenter till ett CRM eller ERP ligger under protokollet. Våra tjänster för AI-integration i CRM börjar med en genomgång av datamodellen, dubbletter och saknade poster, fältanvändning och behörigheter. Agenterna som vi sedan bygger körs under en CRM-användare med avgränsad åtkomst, tillämpar varje persons behörigheter och loggar varje ändring, så att varje uppdatering kan spåras och återställas. De börjar med att föreslå uppdateringar som en person godkänner, och ett steg får köras på egen hand först när dess felfrekvens är tillräckligt låg.
På ERP-sidan är grundarbetet ofta ett API-lager som inte finns ännu. För ett energiutrustningsföretag i Storbritannien, vars affärsområden kördes på Microsoft Dynamics 365, SAP Business One och kalkylark, byggde vi ett centralt API-lager och en dataplattform som synkroniserar alla i realtid: den grund som en agent, eller en MCP-server, behöver under sig. Våra tjänster för ERP-utveckling omfattar samma arbete för SAP, NetSuite och Odoo.
MCP är också en del av hur vi levererar. I en SAP-integrerad tillverkningsapp som byggdes av en AI Pod körde teamet sitt utvecklingsflöde på MCP, återanvändbara promptbibliotek och specialiserade subagenter, och levererade MVP:n 63 % snabbare med ett 56 % mindre leveransteam.
Slutsats
Frågan MCP vs API har ett enklare svar än förkortningarna antyder. MCP är lagret som låter vilken AI-agent som helst hitta och använda det som dina system kan göra; API:erna under gör fortfarande jobbet. Börja med den MCP-server som din CRM- eller ERP-leverantör levererar, lägg till en egen server ovanpå API:et där agenten behöver logik som leverantören inte exponerar, och behåll den iPaaS som redan kör dina integrationer.
Det är sällan anslutningen som håller tillbaka ett projekt. Rena poster, affärsregler som någon har skrivit ner och skrivåtkomst som utökas ett steg i taget avgör om en agent kan betros med arbete i ditt CRM och ERP, och alla tre är värda att lösa innan den första agenten tas i drift.
