Din salgschef spørger en AI-assistent, hvilke deals der gled i dette kvartal, og den svarer ud fra et regneark, som nogen eksporterede i mandags. Din driftschef vil have en agent til at opdatere ordrestatus i NetSuite, og IT spørger, hvem der skal bygge connectoren, hvem der skal vedligeholde den, og hvad agenten skal have lov til at ændre. Et sted i den samtale dukker et nyt akronym op: MCP.
Det korte svar på MCP vs API er, at MCP ikke erstatter dine API’er. Det ligger oven på dem. Et API er den måde, ét system taler med et andet på; Model Context Protocol er en standardiseret måde at beskrive, hvad et system kan, så enhver AI-agent kan finde disse funktioner og bruge dem. Når du vil forbinde AI-agenter med et CRM eller ERP, så start med den MCP-server, din leverandør allerede leverer, byg videre på API’et, hvor den ikke slår til, og behold din iPaaS, hvor den allerede driver dine integrationer. Denne guide forklarer, hvordan de tre hænger sammen, hvad MCP-serverne fra Salesforce, HubSpot, NetSuite og SAP faktisk tillader, og hvordan du lader en agent skrive til dine poster uden at ødelægge dem.
- MCP er et lag oven på API’er: En MCP-server kalder som regel de samme API’er, som dine integrationer allerede bruger.
- Salesforce, HubSpot og NetSuite leverer nu deres egne MCP-servere, og hver af dem kører med rettighederne for den person, der forbinder den.
- En agent, der kan skrive til et CRM eller ERP, har brug for snævre værktøjer, godkendelse af ændringer med konsekvenser og en log over hver handling, uanset hvilken forbindelsesmetode den bruger.
- MCP og RAG løser forskellige opgaver: RAG svarer ud fra dokumenter; MCP lader en agent forespørge og handle i live-systemer.
MCP vs API: Det korte svar
Et API er skrevet til udviklere. Det udstiller endpoints, og en udvikler skriver kode, der kalder dem i en fast rækkefølge til et kendt formål. En AI-agent kan kun bruge et API gennem kode, som nogen har skrevet til netop den agent: en funktionsdefinition, et autentificeringsflow og fejlhåndtering, bygget forfra til hvert AI-værktøj, du tager i brug.
MCP er skrevet til AI-klienter. En MCP-server beskriver sine værktøjer, de data, den kan returnere, og de input, hvert værktøj kræver, i et format, som enhver MCP-kompatibel klient kan læse under kørsel: Claude, ChatGPT, Microsoft Copilot Studio, kodeassistenter og agent-frameworks. Forbind serveren én gang, og alle kompatible klienter kan se, hvad den tilbyder. Anthropic introducerede MCP som en åben standard i november 2024, og i december 2025 blev den flyttet til Agentic AI Foundation under Linux Foundation.
MCP vs API-eksempel: Én opgave, to måder
Tag én anmodning: Flyt en HubSpot-deal til næste fase. Via API’et skriver en udvikler kode, der logger ind, finder dealen, slår de fase-ID’er op, som pipelinen bruger, og sender opdateringen; assistenten kan kun udløse den kode. Via MCP læser en agent, der er forbundet til HubSpot MCP-serveren, listen over de værktøjer, serveren tilbyder, vælger det, der opdaterer en deal, og kalder det med dealen og den nye fase. Serveren foretager det samme API-kald nedenunder, som den person, der forbandt den.
Hvorfor ikke lade modellen kalde API’et direkte?
En kompetent model kan læse et API’s dokumentation eller dets OpenAPI-specifikation og selv skrive kaldene, og for en enkelt udvikler, der afprøver noget, fungerer det. I et forretningssystem ligger det arbejde, der betyder noget, omkring selve kaldet: at logge ind som den rigtige person, afvise handlinger, som den person ikke må udføre, holde sig inden for rate limits og returnere fejl, som agenten kan handle på. En MCP-server gør det én gang, i testet kode, i stedet for at lade hver agent improvisere det ved hver anmodning.
Hvad MCP tilføjer oven på et API, og hvad det ikke gør
Indvendigt tilbyder en MCP-server tre slags byggeklodser, defineret i MCP-specifikationen. Værktøjer er handlinger, agenten kan kalde, som at slå en konto op eller oprette en sag. Ressourcer er skrivebeskyttede data, som en post eller et databaseskema, som applikationen giver modellen som kontekst. Prompts er færdige instruktioner, som en bruger vælger for at starte en opgave. En server kører enten lokalt, på samme maskine som AI-klienten, eller remote over HTTP, hvor den betjener mange brugere, og hvor protokollen anbefaler OAuth til login.
Et punkt, som mange sammenligninger stadig tager fejl af: MCP er ikke en stateful protokol. Siden protokollens version fra 2026-07-28 medsender hver anmodning protokolversionen og de funktioner, serveren har brug for, så serveren behandler hver anmodning for sig, meget ligesom et REST API gør. Beskrivelser af MCP som stateful og API’er som stateless henviser til tidligere versioner.
MCP fjerner gentaget arbejde. Uden det skal hvert AI-værktøj, din virksomhed tager i brug, have sin egen connector til hvert system. Med det bygges connectoren én gang, som en MCP-server, og AI-værktøjerne kan skiftes ud omkring den. Det standardiserer også, hvordan en agent logger ind: Remote MCP-servere bruger OAuth, så agenten handler som en bestemt person.
Hvordan værktøjerne er designet, betyder mere end hvor mange der er. Hvert værktøj, en server udstiller, beskrives for modellen, og de beskrivelser optager den kontekst, modellen ræsonnerer i. En server, der spejler hvert eneste API-endpoint, giver derfor agenten en lang liste at vælge fra og flere måder at vælge forkert på. Servere, der fungerer godt, udstiller et mindre sæt værktøjer på niveau med en forretningshandling, som “opdater ordrestatus”, og foretager endpoint-kaldene bag hvert af dem.
Det, MCP ikke løser, er alt det, der ligger nedenunder. Hvis dit CRM er fyldt med dublerede konti, læser en agent bare dubletterne hurtigere. Hvis et API har rate limits, arver MCP-serveren begrænsningen. Hvis den forretningsregel, der afgør, om en ordre kan ændres, kun findes i nogens hoved, vil ingen protokol finde den. Og hvis et ældre ERP slet ikke har et brugbart API, er der intet for en MCP-server at pakke ind, før nogen bygger et. Derfor er forbindelsesspørgsmålet som regel den mindste del af et projekt med AI CRM-integration; data og regler tager længere tid.
Hvor iPaaS passer ind
Mange mellemstore virksomheder kører allerede deres integrationer gennem en iPaaS som MuleSoft, Workato eller Boomi, og de platforme er ved at tilføje MCP-understøttelse. Tjek, hvad den udstiller, før du planlægger ud fra den: En MCP-server til at administrere integrationsplatformen er ikke det samme som en, der gør dine integrationer til agentværktøjer.
Hvis dine integrationer allerede ligger i en iPaaS, så start der: Den fejlhåndtering, de genforsøg og den overvågning, dit team har bygget til de flows, følger med. Hvis de ikke gør, er en iPaaS sjældent værd at købe bare for at komme til MCP, fordi CRM- og ERP-leverandørerne nu selv leverer MCP-servere.
MCP-servere, som dit CRM og ERP allerede leverer
Før nogen bygger en specialudviklet server, så tjek, hvad leverandøren stiller til rådighed. Her er, hvad fire udbredte platforme tilbyder, sådan som deres egen dokumentation beskrev det, da vi tjekkede i november 2026.
Salesforce MCP
Salesforces MCP-understøttelse kommer som Salesforce Hosted MCP Servers, Salesforces generelt tilgængelige implementering af standarden. Værktøjerne kører med rettighederne for den bruger, der har autentificeret sig, og sikkerhed på feltniveau, objektrettigheder og delingsregler gælder for hvert værktøjskald. Nogle af standardserverne er stadig i beta, og hostede servere er tiltænkt kunder med Flex Credits, hvor forbruget kan blive faktureret, så tjek begge dele, før du planlægger ud fra en af dem. Hvor standardserverne stopper, lader Salesforce dig oprette specialudviklede servere ved siden af; at bygge en er Salesforce-udvikling, med samme test og gennemgang af rettigheder som enhver anden specialudviklet integration.
HubSpot MCP-server
Den remote HubSpot MCP-server blev generelt tilgængelig for alle HubSpot-konti den 13. april 2026. Den læser CRM-poster, marketingindhold og aktiviteter, og den kan oprette og opdatere kontakter, virksomheder, deals, sager, linjeposter, produkter og aktiviteter. Tilbud, fakturaer og ordrer forbliver skrivebeskyttede. Forbindelser bruger OAuth 2.1 med PKCE, og hver handling respekterer brugerens eksisterende HubSpot-rettigheder. Hvis en konto har slået følsomme data til, blokeres aktiviteter helt fra serveren.
NetSuite MCP
Oracle forbinder NetSuite med AI-klienter gennem NetSuite AI Connector Service, som kører på MCP. Adgangen følger rettighederne for NetSuite-roller. SuiteApp’en MCP Standard Tools lader en agent oprette, læse og opdatere poster, køre rapporter og gemte søgninger og forespørge med SuiteQL, som er skrivebeskyttet. Selve tjenesten er ikke en betalt funktion, selvom den AI-klient, du forbinder, kan være det.
SAP MCP-server
SAPs understøttelse er fordelt på flere produkter frem for én server. Agenter bygget i Joule Studio understøtter MCP og Agent2Agent, og SAP Integration Suite indeholder en MCP Gateway, der udstiller eksisterende API’er og integrationsflows som MCP-værktøjer. SAPs referencearkitektur beskriver, hvordan tredjeparts MCP-servere når SAP-systemer på BTP. For de fleste SAP-kunder betyder det, at vejen til MCP går gennem det integrationslag, de allerede har. At etablere den vej er en del af vores SAP-konsulentydelser.
Hvad en agent må se
Hver leverandørserver ovenfor træffer det samme designvalg: Agenten handler som den person, der forbandt den, ikke som en delt servicekonto. Det er den rigtige standard, og den er værd at holde fast i, når du bygger dine egne forbindelser. En integrationskonto med bred adgang, der er koblet til en AI-assistent, giver hver medarbejder, der kan tale med assistenten, den kontos adgang.
Samme princip gælder for søgning i dokumenter. En assistent, der svarer ud fra virksomhedens dokumenter, bør kun se det, som den person, der spørger, har lov til at se. For en IT-servicevirksomhed i Storbritannien byggede vi en retrieval-platform på AWS, der søger på tværs af SharePoint, Salesforce og S3 ét sted, og den gav 60 % hurtigere arbejde med virksomhedens dokumenter. Platformen holder indekset i takt med hvert kildesystem og anvender hver brugers adgangsrettigheder på hvert svar. Det er den svære del af et projekt som dette, ikke selve søgningen.
MCP-sikkerhed har også en side på protokolniveau: hvad hvert værktøj må gøre, hvilke input det accepterer, og hvordan en prompt, der er sneget ind i et dokument eller en e-mail, kan få en agent til at kalde et værktøj, den ikke burde. De risici hører hjemme i samme gennemgang som ethvert andet system med skriveadgang.
Lad en agent skrive tilbage uden at ødelægge poster
Læsning er den nemme del. Spørgsmålet, som enhver CRM- og ERP-ejer stiller, er, hvad der sker, når agenten skriver. Leverandørernes egne valg peger på svaret: Start snævert, og udvid adgangen ét trin ad gangen.
- Skrivebeskyttet først. Agenten besvarer spørgsmål og udarbejder ændringer som forslag. Folk ser, hvad den ville gøre, før den gør noget.
- Snævre skriveværktøjer. I stedet for ét værktøj, der kan opdatere ethvert felt, giver du agenten værktøjer til specifikke handlinger: registrer et opkald, flyt en deal til næste fase, opret en sag.
- Godkendelse af ændringer med konsekvenser. Alt over en aftalt tærskel, som en pris, en kreditgrænse eller en sletning, går til et menneske.
- Sikre genforsøg. En skrivning, der forsøges igen efter en timeout, må ikke oprette en ekstra post. Hver handling har en nøgle, der gør gentagelser harmløse.
- En log over hver handling. Hvad agenten læste, hvad den ændrede, og på hvis vegne.
- En vej tilbage. Den tidligere værdi gemmes, så en forkert ændring kan rulles tilbage uden at gendanne en backup.
For en amerikansk byggeentreprenør sorterer vores e-mail-AI-agent indgående dokumenter og arkiverer dem i Procore og SharePoint, og den gjorde dokumentindlæsningen 70–80 % hurtigere. Mønstret ovenfor er det, der gør det muligt for en agent som den at skrive i systemer, som en virksomhed er afhængig af, og det hører hjemme i første release af enhver AI-agent, ikke i en rettelse efter den første forkerte skrivning.
MCP vs RAG: Forskellige opgaver
MCP vs RAG er ikke et valg mellem alternativer. Retrieval-augmented generation finder de rigtige passager i dine dokumenter og giver dem til modellen, så den kan svare ud fra din virksomheds viden frem for ud fra sin træning. MCP giver en agent adgang til live-systemer, så den kan slå en post op, som den ser ud lige nu, og handle på den.
En salgsassistent viser forskellen. “Hvad er vores standardpolitik for rabat ved fornyelser?” er et RAG-spørgsmål: Svaret står i et politikdokument. “Hvilke af mine fornyelser denne måned ligger over den rabat?” er et MCP-spørgsmål: Svaret findes i CRM’et. De fleste nyttige assistenter har brug for begge dele, og begge afhænger af det samme fundament: pipelines, der holder kilderne opdaterede, og det er den data engineering, der ligger under enhver AI, som svarer ud fra virksomhedens data.
Hvornår du skal bruge MCP, et API eller en iPaaS
Ældre ERP uden brugbart API
Ældre ERP-systemer er det sværeste tilfælde. Hvis systemet udstiller en database, men intet API, er den sikrere vej en læsereplika eller et lille API-lag foran den, hvor skriveoperationer går gennem en kø, som ERP’ets egen logik behandler. Det lag kan derefter pakkes ind som en MCP-server ligesom ethvert andet. Skærmautomatisering via RPA er sidste udvej: Det virker, men det går i stykker, hver gang brugerfladen ændres. Hvor selve systemet er flaskehalsen, kan modernisering af legacy-software koste mindre over tid end at holde en wrapper kørende omkring det, så sammenlign de to muligheder, før du binder dig til en af dem.
Sådan forbinder Crunch-IS AI-agenter med CRM og ERP
Det meste af arbejdet med at forbinde AI-agenter med et CRM eller ERP ligger under protokollen. Vores AI CRM-integrationsydelser starter med en gennemgang af datamodellen, dublerede og manglende poster, feltbrug og adgangsrettigheder. De agenter, vi derefter bygger, kører under en CRM-bruger med afgrænset adgang, anvender hver persons adgangsrettigheder og logger hver ændring, så enhver opdatering kan spores og rulles tilbage. De begynder med at foreslå opdateringer, som en person godkender, og et trin kører først på egen hånd, når fejlraten er lav nok.
På ERP-siden er fundamentet ofte et API-lag, der endnu ikke findes. For en britisk virksomhed inden for energiudstyr, hvis forretningsområder kørte på Microsoft Dynamics 365, SAP Business One og regneark, byggede vi et centralt API-lag og en dataplatform, der synkroniserer dem alle i realtid: det fundament, som en agent eller en MCP-server har brug for nedenunder. Vores ERP-udviklingsydelser dækker det samme arbejde for SAP, NetSuite og Odoo.
MCP er også en del af den måde, vi leverer på. På en SAP-integreret produktionsapp bygget af en AI Pod kørte teamet sit udviklingsworkflow på MCP, genanvendelige promptbiblioteker og specialiserede subagenter og leverede MVP’en 63 % hurtigere med et 56 % mindre leveranceteam.
Konklusion
Spørgsmålet om MCP vs API har et enklere svar, end akronymerne antyder. MCP er det lag, der lader enhver AI-agent finde og bruge det, dine systemer kan; API’erne nedenunder udfører stadig arbejdet. Start med den MCP-server, din CRM- eller ERP-leverandør leverer, tilføj en specialudviklet server oven på API’et, hvor agenten har brug for logik, som leverandøren ikke udstiller, og behold den iPaaS, der allerede driver dine integrationer.
Forbindelsen er sjældent det, der holder et projekt tilbage. Rene poster, forretningsregler, som nogen har skrevet ned, og skriveadgang, der udvides ét trin ad gangen, afgør, om man kan stole på en agent inde i dit CRM og ERP, og alle tre er værd at få på plads, før den første agent går live.
