Salgssjefen din spør en AI-assistent hvilke avtaler som gled ut dette kvartalet, og den svarer ut fra et regneark noen eksporterte på mandag. Driftslederen din vil ha en agent som oppdaterer ordrestatus i NetSuite, og IT spør hvem som skal bygge koblingen, hvem som skal vedlikeholde den, og hva agenten skal få lov til å endre. Et sted i den samtalen dukker et nytt akronym opp: MCP.
Det korte svaret på MCP vs API er at MCP ikke erstatter API-ene dine. Det ligger oppå dem. Et API er måten ett system snakker med et annet på; Model Context Protocol er en standardisert måte å beskrive hva et system kan gjøre, slik at enhver AI-agent kan finne disse funksjonene og bruke dem. For å koble AI-agenter til et CRM eller ERP starter du med MCP-serveren leverandøren din allerede leverer, bygger på API-et der den kommer til kort, og beholder iPaaS-løsningen der den allerede kjører integrasjonene dine. Denne guiden forklarer hvordan de tre henger sammen, hva MCP-serverne fra Salesforce, HubSpot, NetSuite og SAP faktisk tillater, og hvordan du lar en agent skrive til postene dine uten å ødelegge dem.
- MCP er et lag over API-er: en MCP-server kaller vanligvis de samme API-ene som integrasjonene dine allerede bruker.
- Salesforce, HubSpot og NetSuite leverer nå egne MCP-servere, og hver av dem kjører med tillatelsene til personen som kobler den til.
- En agent som kan skrive til et CRM eller ERP, trenger smale verktøy, godkjenning for endringer med konsekvenser og en logg over hver handling, uansett hvilken tilkoblingsmetode den bruker.
- MCP og RAG gjør ulike jobber: RAG svarer ut fra dokumenter; MCP lar en agent hente data og utføre handlinger i systemene i sanntid.
MCP vs API: Det korte svaret
Et API er skrevet for utviklere. Det publiserer endepunkter, og en utvikler skriver kode som kaller dem i fast rekkefølge for et kjent formål. En AI-agent kan bare bruke et API gjennom kode noen har skrevet for akkurat den agenten: en funksjonsdefinisjon, en autentiseringsflyt og feilhåndtering, bygget på nytt for hvert AI-verktøy du tar i bruk.
MCP er skrevet for AI-klienter. En MCP-server beskriver verktøyene sine, dataene den kan returnere og hvilke inndata hvert verktøy trenger, i et format enhver MCP-kompatibel klient kan lese under kjøring: Claude, ChatGPT, Microsoft Copilot Studio, kodeassistenter og agentrammeverk. Koble til serveren én gang, så kan alle kompatible klienter oppdage hva den tilbyr. Anthropic lanserte MCP som en åpen standard i november 2024, og i desember 2025 ble den flyttet til Agentic AI Foundation under Linux Foundation.
MCP vs API-eksempel: Én oppgave, to måter
Ta én forespørsel: flytt en HubSpot-avtale til neste fase. Via API-et skriver en utvikler kode som logger inn, finner avtalen, slår opp fase-ID-ene pipelinen bruker, og sender oppdateringen; assistenten kan bare utløse den koden. Via MCP leser en agent som er koblet til HubSpot MCP-serveren, listen over verktøy serveren tilbyr, velger det som oppdaterer en avtale, og kaller det med avtalen og den nye fasen. Serveren gjør det samme API-kallet i bakgrunnen, som personen som koblet den til.
Hvorfor ikke la modellen kalle API-et direkte?
En dyktig modell kan lese dokumentasjonen til et API eller OpenAPI-spesifikasjonen og skrive kallene selv, og for én utvikler som prøver noe ut, fungerer det. I et forretningssystem ligger det viktige arbeidet rundt selve kallet: å logge inn som riktig person, avvise handlinger den personen ikke har lov til, holde seg innenfor grensene for antall kall og returnere feil agenten kan handle på. En MCP-server gjør dette én gang, i testet kode, i stedet for å overlate til hver agent å improvisere det ved hver forespørsel.
Hva MCP legger til oppå et API, og hva det ikke gjør
Internt tilbyr en MCP-server tre typer byggeklosser, definert i MCP-spesifikasjonen. Verktøy (tools) er handlinger agenten kan kalle, for eksempel å slå opp en konto eller opprette en sak. Ressurser (resources) er skrivebeskyttede data, for eksempel en post eller et databaseskjema, som applikasjonen gir modellen som kontekst. Prompter (prompts) er ferdige instruksjoner en bruker velger for å starte en oppgave. En server kjører enten lokalt, på samme maskin som AI-klienten, eller eksternt over HTTP, der den betjener mange brukere og protokollen anbefaler OAuth for innlogging.
Ett punkt mange sammenligninger fortsatt tar feil av: MCP er ikke en tilstandsbasert protokoll. Siden protokollversjonen fra 2026-07-28 har hver forespørsel med seg protokollversjonen og funksjonene serveren trenger, slik at serveren håndterer hver forespørsel for seg, omtrent slik et REST API gjør. Beskrivelser av MCP som tilstandsbasert og API-er som tilstandsløse gjelder tidligere versjoner.
MCP fjerner gjentatt arbeid. Uten MCP trenger hvert AI-verktøy bedriften din tar i bruk, sin egen kobling til hvert system. Med MCP bygges koblingen én gang, som en MCP-server, og AI-verktøyene kan skiftes ut rundt den. Protokollen standardiserer også hvordan en agent logger inn: eksterne MCP-servere bruker OAuth, så agenten handler som en bestemt person.
Hvordan verktøyene er utformet, betyr mer enn hvor mange det er. Hvert verktøy en server eksponerer, beskrives for modellen, og disse beskrivelsene tar opp konteksten modellen resonnerer i. En server som speiler hvert eneste API-endepunkt, gir derfor agenten en lang liste å velge fra og flere måter å velge feil på. Servere som fungerer godt, eksponerer et mindre sett verktøy på nivå med en forretningshandling, som «oppdater ordrestatus», og gjør endepunktkallene bak hvert av dem.
Det MCP ikke fikser, er alt som ligger under. Hvis CRM-et ditt er fullt av dupliserte kontoer, leser en agent duplikatene raskere. Hvis et API har begrensning på antall kall, arver MCP-serveren begrensningen. Hvis forretningsregelen som avgjør om en ordre kan endres, bare finnes i hodet til noen, vil ingen protokoll finne den. Og hvis et eldre ERP ikke har noe brukbart API i det hele tatt, finnes det ingenting en MCP-server kan pakke inn før noen bygger et. Derfor er tilkoblingsspørsmålet vanligvis den minste delen av et prosjekt for AI CRM-integrasjon; dataene og reglene tar lengre tid.
Hvor iPaaS passer inn
Mange mellomstore bedrifter kjører allerede integrasjonene sine gjennom en iPaaS som MuleSoft, Workato eller Boomi, og disse plattformene legger nå til MCP-støtte. Sjekk hva den eksponerer før du planlegger rundt den: en MCP-server for å administrere integrasjonsplattformen er ikke det samme som en som gjør integrasjonene dine om til verktøy for agenter.
Hvis integrasjonene dine allerede ligger i en iPaaS, start der: feilhåndteringen, de automatiske nye forsøkene og overvåkingen teamet ditt bygde for disse flytene, følger med. Hvis ikke, er en iPaaS sjelden verdt å kjøpe bare for å få MCP, fordi CRM- og ERP-leverandørene nå leverer egne MCP-servere.
MCP-servere som CRM- og ERP-systemet ditt allerede leverer
Før noen bygger en egen server, bør du sjekke hva leverandøren tilbyr. Her er hva fire vanlige plattformer tilbyr, slik deres egen dokumentasjon beskrev det da vi sjekket i november 2026.
Salesforce MCP
Salesforce har MCP-støtte i form av Salesforce Hosted MCP Servers, Salesforces allment tilgjengelige implementering av standarden. Verktøyene kjører med tillatelsene til brukeren som autentiserte seg, og sikkerhet på feltnivå, objekttillatelser og delingsregler gjelder for hvert verktøykall. Noen av standardserverne er fortsatt i beta, og de hostede serverne er beregnet på kunder med Flex Credits, med bruk som kan bli fakturert, så sjekk begge deler før du planlegger rundt en av dem. Der standardserverne stopper, lar Salesforce deg lage egne servere ved siden av; å bygge en slik server er Salesforce-utvikling, med samme testing og gjennomgang av tillatelser som enhver skreddersydd integrasjon.
HubSpot MCP-server
Den eksterne HubSpot MCP-serveren ble allment tilgjengelig for alle HubSpot-kontoer 13. april 2026. Den leser CRM-poster, markedsføringsinnhold og aktiviteter, og den kan opprette og oppdatere kontakter, selskaper, avtaler, saker, ordrelinjer, produkter og aktiviteter. Tilbud, fakturaer og ordrer er skrivebeskyttet. Tilkoblinger bruker OAuth 2.1 med PKCE, og hver handling respekterer brukerens eksisterende HubSpot-tillatelser. Hvis en konto har sensitive data slått på, blokkeres aktiviteter helt fra serveren.
NetSuite MCP
Oracle kobler NetSuite til AI-klienter gjennom NetSuite AI Connector Service, som kjører på MCP. Tilgangen følger rolletillatelsene i NetSuite. SuiteApp-en MCP Standard Tools lar en agent opprette, lese og oppdatere poster, kjøre rapporter og lagrede søk og gjøre spørringer med SuiteQL, som er skrivebeskyttet. Selve tjenesten er ikke en betalt funksjon, men AI-klienten du kobler til, kan være det.
SAP MCP-server
SAPs støtte er spredt over flere produkter i stedet for én server. Agenter bygget i Joule Studio støtter MCP og Agent2Agent, og SAP Integration Suite inneholder en MCP Gateway som eksponerer eksisterende API-er og integrasjonsflyter som MCP-verktøy. SAPs referansearkitektur beskriver hvordan tredjeparts MCP-servere når SAP-systemer på BTP. For de fleste SAP-kunder betyr det at veien til MCP går gjennom integrasjonslaget de allerede har. Å sette opp den veien er en del av våre SAP-konsulenttjenester.
Hva en agent får lov til å se
Alle leverandørserverne ovenfor gjør det samme designvalget: agenten handler som personen som koblet den til, ikke som en delt tjenestekonto. Det er riktig standardvalg, og det er verdt å beholde når du bygger egne tilkoblinger. En integrasjonskonto med bred tilgang, koblet til en AI-assistent, gir alle ansatte som kan snakke med assistenten, den kontoens tilgang.
Det samme prinsippet gjelder for gjenfinning. En assistent som svarer ut fra bedriftsdokumenter, skal bare se det personen som spør, har lov til å se. For et IT-tjenesteselskap i Storbritannia bygde vi en gjenfinningsplattform på AWS som søker på tvers av SharePoint, Salesforce og S3 på ett sted, og den ga 60 % raskere arbeid med bedriftsdokumenter. Plattformen holder indeksen synkronisert med hvert kildesystem og bruker hver brukers tilgangsrettigheter på hvert svar. Det, ikke søket, er den vanskelige delen av et slikt prosjekt.
MCP-sikkerhet har også en side på protokollnivå: hva hvert verktøy får lov til å gjøre, hvilke inndata det godtar, og hvordan en prompt som er injisert i et dokument eller en e-post, kan styre en agent til å kalle et verktøy den ikke burde kalle. Disse risikoene hører hjemme i samme gjennomgang som ethvert annet system med skrivetilgang.
Slik lar du en agent skrive tilbake uten å ødelegge poster
Lesing er den enkle delen. Spørsmålet alle CRM- og ERP-eiere stiller, er hva som skjer når agenten skriver. Leverandørenes egne valg peker mot svaret: start smalt og utvid tilgangen ett steg om gangen.
- Skrivebeskyttet først. Agenten svarer på spørsmål og utarbeider endringer som forslag. Folk ser hva den ville gjort, før den gjør noe.
- Smale skriveverktøy. I stedet for ett verktøy som kan oppdatere et hvilket som helst felt, gir du agenten verktøy for bestemte handlinger: logge en samtale, flytte en avtale til neste fase, opprette en sak.
- Godkjenning for endringer med konsekvenser. Alt over en avtalt terskel, for eksempel en pris, en kredittgrense eller en sletting, går til en person.
- Trygge nye forsøk. En skriving som prøves på nytt etter et tidsavbrudd, må ikke opprette en ny post. Hver handling har en nøkkel som gjør gjentakelser ufarlige.
- En logg over hver handling. Hva agenten leste, hva den endret, og på vegne av hvem.
- En vei tilbake. Den forrige verdien lagres, slik at en feil endring kan reverseres uten å gjenopprette en sikkerhetskopi.
For en byggentreprenør i USA sorterer vår AI-agent for e-post innkommende dokumenter og arkiverer dem i Procore og SharePoint, og den gjorde dokumentmottaket 70–80 % raskere. Mønsteret ovenfor er det som lar en slik agent skrive inn i systemer en virksomhet er avhengig av, og det hører hjemme i første versjon av enhver AI-agent, ikke i en rettelse etter den første feilaktige skrivingen.
MCP vs RAG: Ulike jobber
MCP vs RAG er ikke et valg mellom alternativer. Retrieval-augmented generation (RAG) finner de riktige avsnittene i dokumentene dine og gir dem til modellen, slik at den kan svare ut fra kunnskapen din i stedet for treningsdataene sine. MCP gir en agent tilgang til systemer i sanntid, slik at den kan slå opp en post slik den ser ut akkurat nå, og handle på den.
En salgsassistent viser forskjellen. «Hva er standard rabattpolicy for fornyelser?» er et RAG-spørsmål: svaret står i et policydokument. «Hvilke av fornyelsene mine denne måneden ligger over den rabatten?» er et MCP-spørsmål: svaret ligger i CRM-et. De fleste nyttige assistenter trenger begge deler, og begge avhenger av det samme grunnarbeidet: datapipelines som holder kildene oppdatert, altså dataingeniørarbeidet som ligger under all AI som svarer ut fra bedriftsdata.
Når du bør bruke MCP, et API eller en iPaaS
Eldre ERP uten brukbart API
Eldre ERP-systemer er det vanskeligste tilfellet. Hvis systemet eksponerer en database, men ikke noe API, er den tryggere veien en lesereplika eller et lite API-lag foran det, der skriveoperasjoner går gjennom en kø som ERP-systemets egen logikk behandler. Det laget kan deretter pakkes inn som en MCP-server som alle andre. Skjermautomatisering gjennom RPA er siste utvei: det fungerer, men det brekker hver gang grensesnittet endres. Der selve systemet er flaskehalsen, kan modernisering av eldre programvare koste mindre over tid enn å holde liv i en innpakning rundt det, så sammenlign de to før du forplikter deg til en av dem.
Slik kobler Crunch-IS AI-agenter til CRM og ERP
Det meste av arbeidet med å koble AI-agenter til et CRM eller ERP ligger under protokollen. Våre AI CRM-integrasjonstjenester starter med en gjennomgang av datamodellen, dupliserte og manglende poster, feltbruk og tilgangsrettigheter. Agentene vi deretter bygger, kjører under en CRM-bruker med avgrenset tilgang, bruker hver persons tilgangsrettigheter og logger hver endring, slik at enhver oppdatering kan spores og reverseres. De begynner med å foreslå oppdateringer som en person godkjenner, og et steg kjører først på egen hånd når feilraten er lav nok.
På ERP-siden er grunnarbeidet ofte et API-lag som ikke finnes ennå. For et britisk selskap innen energiutstyr, der forretningsområdene kjørte på Microsoft Dynamics 365, SAP Business One og regneark, bygde vi et sentralt API-lag og en dataplattform som synkroniserer alle sammen i sanntid: fundamentet en agent, eller en MCP-server, trenger under seg. Våre ERP-utviklingstjenester dekker det samme arbeidet for SAP, NetSuite og Odoo.
MCP er også en del av hvordan vi leverer. På en SAP-integrert produksjonsapp bygget av en AI Pod kjørte teamet utviklingsarbeidsflyten sin på MCP, gjenbrukbare promptbiblioteker og spesialiserte subagenter, og leverte MVP-en 63 % raskere med et 56 % mindre leveranseteam.
Konklusjon
MCP vs API-spørsmålet har et enklere svar enn akronymene gir inntrykk av. MCP er laget som lar enhver AI-agent finne og bruke det systemene dine kan gjøre; API-ene under gjør fortsatt jobben. Start med MCP-serveren CRM- eller ERP-leverandøren din leverer, legg til en egen server oppå API-et der agenten trenger logikk leverandøren ikke eksponerer, og behold iPaaS-løsningen som allerede kjører integrasjonene dine.
Det er sjelden tilkoblingen som holder et prosjekt tilbake. Ryddige poster, forretningsregler som noen har skrevet ned, og skrivetilgang som utvides ett steg om gangen, avgjør om en agent kan stoles på inne i CRM- og ERP-systemet ditt, og alle tre er verdt å få på plass før den første agenten settes i drift.
