Denne blog-artikkelen ble opprinnelig publisert 18. november 2025 og er senere oppdatert.
Av Tomydas Pall, Gruppeproduktsjef
Et teammedlem spurte meg nylig: “Når vi tar i bruk MCP og det kobler sammen alt, hvorfor skal vi da i det hele tatt trenge API-er? Vil API-ene forsvinne?”
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, trenger man kanskje ikke 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 ekte eksempel.
API-er: Grunnlaget for tilkobling
API-er har vært ryggraden i digitale systemer i årtier. De definerer hvordan applikasjoner snakker med hverandre – henter data, utfører handlinger og driver integrasjoner.
Ta et system for utgiftshåndtering som Concur:
POST /expenses/{id}/approve → godkjenne en utgift
Uten API-er finnes det ingen måte for andre systemer å samhandle på en pålitelig måte med denne applikasjonen. API-er er veiene i bedriftsprogramvaren.
Legger til AI-laget
Nå kan vi prøve å legge til et AI-lag for å automatisere disse interaksjonene.
Tenk deg at en leder i stedet for å skrive kommandoer eller klikke seg gjennom menyer ganske enkelt spør i Slack:
Eller senere:
Her er det 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 ha kontaktet Concur-API-ene direkte – men uten sterke sikkerhetskoplinger kan det bety overdreven tilgangsstyring, manglende loggføring eller usikker automatisering.
Det er nettopp her MCP kommer inn i bildet.
Vi presenterer MCP: AI-integrert styring
Model Context Protocol (MCP) er ikke ment å erstatte API-er. Det fungerer snarere som en bro som gjør API-er sikre, forståelige og brukbare for AI-agenter.
Slik passer det inn i eksempelet vårt:
MCP-klienten (som kjører i Slack sammen med AI-agenten) sender forespørselen. MCP-serveren (som befinner seg i nærheten av Concur) omslutter Concur-API-ene, sjekker tilgangstillatelser, legger til styringsfunksjoner og loggfører handlinger. Først da blir API-kallet utført av Concur.

API-ene utfører fortsatt oppgavene – men MCP sikrer en sikker, gjennomsiktig og regulert usage.
Støtter ikke API-er allerede kontroll og styring?
Det naturlige neste spørsmålet går vanligvis omtrent slik:
“API-er har allerede OAuth, RBAC, hastighetsbegrensninger og revisjonslogger. Er ikke det styring? Hvorfor trenger vi MCP i tillegg?”
Her er forskjellen:

Styringen av MCP er AI-sentrert. Det sikrer at KI-agenter samhandler på en trygg måte, med retningslinjer skreddersydd for autonomi, forklarbarhet og observerbarhet.
Med andre ord regjerer API-er tilgang, MCP regulerer oppførsel.
Det ekstra laget betyr noe når bedrifter skifter fra menneskedrevne samtaler til autonome AI-drevne arbeidsflyter.
MCP i praksis
MCP vinner raskt terreng, slik følgende eksempler viser:
- Anthropics MCP SDK-er → referanseimplementeringen.
- LangChain og LlamaIndex → utforsker MCP-koblinger for sine agentrammeverk.
- Community MCP-servere → blir stadig mer vanlige 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å godkjenning av utgifter
Selv om slike tilkoblinger selvfølgelig er mulige uten MCP, skal vi her se nærmere på hvordan MCP bidrar til å forenkle og forbedre prosessene:
API-flyt
- Utvikleren bygger en Slack-integrasjon.
- Kommandoer utløser API-kall direkte (GET /expenses, POST /approve).
- Denne flyten fungerer, men den krever egendefinert koding og manuell styring.
MCP Flow
- AI-agenten i Slack kobler seg til via MCP-klienten.
- MCP-klienten videresender forespørselen til MCP-serveren, som fungerer som et grensesnitt for Concur-API-ene.
- MCP-serveren håndhever tilgangsrettigheter, loggføring og kontekst, før den deretter påkaller API-et.
- Concur utfører handlingen og returnerer resultatene til Slack.
- I denne prosessen utfører API-ene selve arbeidet, og MCP sørger for at AI-agentene bruker dem på en sikker måte.
Nye trender som preger debatten om API kontra MCP
Det er flere faktorer som samvirker og som vil endre måten bedrifter tenker på API-er og MCP:
Implementering av agentbasert KI:
Ettersom flere arbeidsflyter flyttes til autonome agenter, vil styringen skifte fra “bruker-til-app”-regler til “agent-til-app”-rammeverk.
Standardisering rundt MCP:
Konkurrerende leverandører samler seg om MCP som en felles løsning for å koble sammen AI-modeller og -verktøy.
KI-observabilitetsplattformer:
Dashbord som sporer agentbeslutninger, API-kall og styringsresultater, er i ferd med å bli et absolutt krav for bedrifter.
Forklaring som sikkerhet:
AI-interaksjoner vil kreve ikke bare logger, men narrativer om hvorfor handlinger ble utført.
Endring i API-design:
Selve API-ene kan utvikle seg til å inkludere “agentvennlige” metadata (tillatelser, trygge standardinnstillinger, risikovurdering) innebygd.
Så, vil API-ene Disappear?
Nei. API-er forsvinner ikke. Tvert imot blir de stadig viktigere, og i fremtiden vil vi se at API-er og MCP utvikler seg i takt for å støtte bedrifter som prioriterer kunstig intelligens.
MCP tilfører styring, standardisering og overvåkbarhet – men API-er utgjør fortsatt grunnlaget. Tenk på det slik: MCP er trafikkreglene og navigasjonssystemet som gjør at AI-agenter kan kjøre trygt på API-veiene.
Ettersom bruken av autonom KI (agentic AI) øker, vil bedrifter ha behov for mer API-er, ikke færre.
Hvordan Jitterbit sikrer MCP
Jitterbit MCP leverer en implementering i bedriftsklasse av Model Context Protocol, som forvandler eksisterende API-er og integrasjoner til gjenbrukbare, agentklare funksjoner. Den etablerer et standardisert kontrollag mellom KI-modeller, agenter og bedriftssystemer, og omdanner eksisterende integrasjoner og API-er til regulerte, gjenbrukbare verktøy.
Jitterbit MCP kombinerer tre kjernefunksjoner i én samlet løsning.


Strategiske hovedpunkter
Hva betyr dette for oss nå?
- API-er utgjør fortsatt grunnlaget. De vil ikke forsvinne – de er fremdeles veiene som transporterer bedriftsdata og -handlinger.
- MCP gjør API-er klare for AI. Ved å regulere atferden, ikke bare tilgangen, sikrer MCP at AI-agenter kan samhandle med API-er på en sikker og gjennomsiktig måte.
- Utviklere bør designe API-er for fremtiden. Hvis du bygger API-er i dag, bør du tenke fremover: Hvordan vil disse API-ene bli eksponert, styrt og overvåket i en KI-først bedrift?
- Det er grunn til å forvente en dobbel satsing. Bedriftene vil måtte styrke både sine API-strategier og innføre MCP-rammeverk for styring.
- I stedet for å gjøre API-er foreldet, gjør MCP dem «AI-first», og hjelper bedrifter med å bruke API-er på en sikker måte i AI-drevne arbeidsflyter.
Fremtiden for AI-nativ tilkobling
Den neste bølgen av bedriftsintegrasjon vil ikke handle om å velge mellom API-er og MCP. Det skyldes at den egentlige debatten ikke dreier seg om API kontra MCP.
I stedet vil det handle om hvor raskt organisasjonene klarer å tilpasse seg, slik at de ser på API-er og MCP som komplementære lag snarere enn konkurrerende alternativer.
Med andre ord: API-er vil ikke forsvinne. Men bedrifter som ikke tilpasser seg dem til MCP-æraen, kan komme til å forsvinne.
