Vil MCP utrydde API-er?

Denne bloggen ble opprinnelig publisert 18. november 2025 og har blitt oppdatert.

Av Tomydas Pall, Gruppe produktsjef

Et teammedlem spurte meg nylig: «Når vi aktiverer MCP og det kobler sammen alt, hvorfor trenger vi i det hele tatt API-er? Vil API-ene bli borte?»

Det spørsmålet fikk meg til å stoppe opp. Først hørtes det opplagt ut – hvis MCP kobler AI-agenter til verktøy og data, er det kanskje ikke behov for API-er lenger. Men jo mer jeg tenkte på det, desto mer innså jeg at svaret ikke er så enkelt.

For å se hvorfor, la oss utforske dette spørsmålet med et eksempel fra virkeligheten.

API-er: Grunnlaget for tilkobling

API-er har vært ryggraden i digitale systemer i flere tiår. De definerer hvordan applikasjoner kommuniserer med hverandre – henter data, kjører handlinger og driver integrasjoner.

Ta et utgiftsstyringssystem som Concur:

Uten API-er kan andre systemer ikke samhandle pålitelig med denne applikasjonen. API-er er veien til bedriftsprogramvare.

Legge til AI-laget

La oss nå prøve å legge til et AI-lag for å automatisere disse interaksjonene.

I stedet for å skrive kommandoer eller klikke deg gjennom menyer, kan du forestille deg at en leder bare spør i Slack:

Eller senere:

Her er hva som skjer: AI-agenten i Slack tolker forespørselen. Den må snakke med Concur for å hente data eller utføre en handling. Tradisjonelt ville den truffet Concur API-ene direkte – men uten sterke sikkerhetstiltak kan det bety overtillatelser, mangel på logging eller usikker automatisering.

Det er nettopp her MCP kommer inn i bildet.

Gå inn i MCP: AI-native governance

Model Context Protocol (MCP) er ikke her for å erstatte API-er. I stedet er det broen som gjør API-er trygge, forklarbare og brukbare for AI-agenter.

Slik passer det inn i vårt eksempel:

MCP-klienten (som kjører inne i Slack med AI-agenten) sender forespørselen. MCP-serveren (som ligger i nærheten av Concur) pakker inn Concur API-ene, sjekker tillatelser, legger til styrings- og loggehandlinger. Først da blir API-kallet utført av Concur.

API-ene gjør fortsatt jobben – men MCP sikrer sikker, transparent og styrt bruk.

Støtter ikke API-er allerede styring?

Det naturlige neste spørsmålet lyder vanligvis omtrent slik:

«API-er har allerede OAuth, RBAC, hastighetsgrenser og revisjonslogger. Er ikke det styring? Hvorfor trenger vi MCP i tillegg?»

Her er forskjellen:

API-styring er app-sentrisk. Det beskytter systemet mot misbruk, og sikrer at brukerne følger reglene.
 
MCP-styring er AI-sentrisk. Det sikrer at AI-agenter samhandler trygt, med beskyttelsesrekkverk skreddersydd for autonomi, forklaringsevne og observerbarhet.

Med andre ord styrer API-er adgang, MCP styrer atferd.

Det ekstra laget er viktig når bedrifter går over fra menneskedrevne anrop til autonome, kunstig intelligens-drevne arbeidsflyter.

MCP i den virkelige verden

MCP vinner raskt fotfeste, som følgende eksempler viser:

• Anthropics MCP SDK-er → referanseimplementeringen.
• LangChain og LlamaIndex → ​​utforsker MCP-kontakter for agentrammeverkene deres.
• MCP-servere i fellesskapet → fremkommer for verktøy som Jira, Slack og GitHub.

Dette signaliserer en trend: bedrifter ønsker en standardisert og sikker måte for agenter å koble seg til forretningssystemer på.

API vs MCP: Eksempel på utgiftsgodkjenning

Selv om slike forbindelser absolutt er mulige uten MCP, ser du her hvordan MCP bidrar til å forenkle og forbedre prosesser:

API-kun flyt

• Utvikler bygger en Slack-integrasjon.
• Kommandoer utløser direkte API-kall (GET /expenses, POST /approve).
• Denne flyten fungerer, men den krever tilpasset koding og manuell styring.

MCP-flyt

• AI-agent i Slack kobler seg til via MCP-klient.
• MCP-klienten videresender forespørselen til MCP-serveren, som pakker inn Concur API-ene.
• MCP-serveren håndhever tillatelser, logging og kontekst, og kaller deretter API-et.
• Concur utfører handlingen og returnerer resultatene til Slack.
• I denne flyten gjør API-ene jobben, og MCP sørger for at AI-agenter bruker dem på en trygg måte.

Se større

Nye trender som former debatten om API og MCP

Flere krefter er i ferd med å møtes og vil endre måten bedrifter tenker på API-er og MCP:

Agentisk AI-adopsjon:

Etter hvert som flere arbeidsflyter går over til autonome agenter, vil styring gå fra «bruker-til-app»-regler til «agent-til-app»-rammeverk.

Standardisering rundt MCP:

Konkurrerende leverandører samles rundt MCP som en vanlig måte å koble sammen AI-modeller og -verktøy på.

AI-observasjonsplattformer:

Dashbord som sporer agentbeslutninger, API-kall og styringsresultater er i ferd med å bli et must for bedrifter.

Forklarbarhet som sikkerhet:

AI-interaksjoner vil ikke bare kreve logger, men fortellinger om hvorfor handlinger ble iverksatt.

Endring i API-design:

API-er kan i seg selv utvikles til å inkludere innebygde «agentvennlige» metadata (tillatelser, sikre standardinnstillinger, risikovurdering).

Så, vil API-er gåsappære?

Nei. API-er kommer ikke til å forsvinne. Faktisk blir de viktigere, og i fremtiden vil vi se API-er og MCP utvikle seg sammen for å støtte AI-fokuserte bedrifter.

MCP legger til styring, standardisering og observerbarhet – men API-er forblir grunnlaget. Tenk på det slik: MCP er trafikkloven og navigasjonssystemet som lar AI-agenter kjøre trygt på API-veier.

Etter hvert som adopsjonen av agentisk AI øker, vil bedrifter trenge mer API-er, ikke færre.

Hvordan Jitterbit Sikrer MCP

Jitterbit MCP leverer en implementering av Model Context Protocol i bedriftsklassen, og transformerer eksisterende API-er og integrasjoner til gjenbrukbare, agentklare funksjoner. Den etablerer et standardisert kontrolllag mellom AI-modeller, agenter og bedriftssystemer, og transformerer eksisterende integrasjoner og API-er til styrte, gjenbrukbare verktøy.

Jitterbit MCP kombinerer tre kjernefunksjoner i én enhetlig løsning.

Strategiske konklusjoner

Så hvor forlater dette oss?

• API-er forblir fundamentet. De vil ikke forsvinne.sappære – de er fortsatt veiene som frakter bedriftsdata og -handlinger.
• MCP gjør API-er klare for AI. Ved å styre atferd, ikke bare tilgang, sikrer MCP at AI-agenter kan samhandle med API-er på en trygg og transparent måte.
• Utviklere bør designe API-er for fremtiden. Hvis du bygger API-er i dag, tenk fremover: Hvordan vil disse API-ene bli eksponert, styrt og observert i en AI-fokusert bedrift?
• Forvent dobbel investering. Bedrifter må styrke begge API-strategiene sine og ta i bruk MCP-rammeverk for styring.
• I stedet for å gjøre API-er foreldet, gjør MCP dem AI-fokuserte, og hjelper bedrifter med å bruke API-er trygt i AI-drevne arbeidsflyter.

Fremtiden for AI-native tilkoblingsmuligheter

Den neste bølgen av bedriftsintegrasjon vil ikke handle om å velge mellom API-er og MCP. Det er fordi den virkelige debatten ikke er API vs. MCP.

I stedet vil det handle om hvor raskt organisasjoner utvikler seg til å behandle API-er og MCP som komplementære lag i stedet for konkurrerende valg.

Med andre ord: API-er kommer ikke til å dø ut. Men bedrifter som ikke tilpasser dem til MCP-æraen, kan gjøre det.