Will MCP Udrydde API'er?

Denne blog blev oprindeligt offentliggjort den 18. november 2025 og er siden blevet opdateret.

Af Tomydas Pall, Group Product Manager

Et medlem af teamet spurgte mig for nylig: “Når vi aktiverer MCP, og det forbinder det hele, hvorfor har vi så overhovedet brug for API’er? Vil API’er forsvinde?”

Det spørgsmål fik mig til at stoppe op. I første omgang lød det indlysende — hvis MCP forbinder AI-agenter med værktøjer og data, er API’er måske ikke længere nødvendige. Men jo mere jeg tænkte over det, desto mere gik det op for mig, at svaret ikke er så enkelt.

For at se hvorfor, lad os udforske dette spørgsmål med et eksempel fra det virkelige liv.

API'er: Fundamentet for konnektivitet

API'er har været rygraden i digitale systemer i årtier. De definerer, hvordan applikationer taler med hinanden — henter data, udfører handlinger og driver integrationer.

Tag et udrulningssystem til udgiftsstyring såsom Concur:

Uden API'er er der ingen måde for andre systemer at interagere pålideligt med denne applikation. API'er er vejene i virksomhedssoftware.

Tilføjelse af AI-laget

Lad os nu prøve at tilføje et AI-lag for at automatisere disse interaktioner.

I stedet for at skrive kommandoer eller klikke gennem menuer, så forestil dig, at en leder blot spørger i Slack:

Eller senere:

Her er hvad der sker: AI-agenten i Slack fortolker forespørgslen. Den skal tale med Concur for at hente data eller udføre en handling. Traditionelt ville den ramme Concur-API'erne direkte — men uden stærke sikkerhedsforanstaltninger kan det betyde overdreven tildeling af rettigheder, manglende logning eller usikker automatisering.

Det er netop her, at MCP kommer ind i billedet.

Her kommer MCP: AI-baseret styring

Model Context Protocol (MCP) er ikke tænkt som en erstatning for API’er. Det fungerer derimod som en bro, der gør API’er sikre, forståelige og anvendelige for AI-agenter.

Sådan passer det ind i vores eksempel:

MCP-klienten (der kører i Slack sammen med AI-agenten) sender anmodningen. MCP-serveren (der er placeret tæt på Concur) indkapsler Concur-API’erne, kontrollerer tilladelser, tilføjer styringsmekanismer og logger handlinger. Først derefter udføres API-kaldet af Concur.

API’erne udfører stadig arbejdet – men MCP sikrer en sikker, gennemsigtig og reguleret usage.

Understøtter API'er ikke allerede governance?

Det naturlige næste spørgsmål lyder normalt i retning af:

“API’er har allerede OAuth, RBAC, hastighedsbegrænsninger og revisionslogfiler. Er det ikke det, man kalder governance? Hvorfor har vi så brug for MCP oven i købet?”

Her er forskellen:

API-governance er app-centreret. Det beskytter systemet mod misbrug og sikrer, at brugerne overholder reglerne.
 
MCP-styring er AI-centreret. Det sikrer, at AI-agenter interagerer sikkert med rammer skræddersyet til autonomi, forklarbarhed og observerbarhed.

Med andre ord styrer API'er adgang, MCP regulerer adførsel.

Det ekstra lag betyder noget, når virksomheder skifter fra menneske-drevne opkald til autonome AI-drevne arbejdsgange.

MCP i den virkelige verden

MCP vinder hurtigt indpas, som de følgende eksempler viser:

• Anthropics MCP SDK’er → referenceimplementeringen.
• LangChain og LlamaIndex → undersøger MCP-konnektorer til deres agent-rammeværker.
• Community MCP-servere → vinder frem til værktøjer som Jira, Slack og GitHub.

Dette signalerer en tendens: virksomheder ønsker en standardiseret og sikker måde for agenter at oprette forbindelse til forretningssystemer på.

API vs. MCP: Eksempel på godkendelse af udgifter

Selvom sådanne tilslutninger naturligvis også er mulige uden MCP, vil vi her se nærmere på, hvordan MCP bidrager til at forenkle og forbedre processerne:

API-kun flow

• Udvikler bygger en Slack-integration.
• Kommandoer udløser direkte API-kald (GET /expenses, POST /approve).
• Dette flow virker, men det kræver tilpasset kodning og manuel styring.

MCP Flow

• AI-agenten i Slack opretter forbindelse via MCP-klienten.
• MCP-klienten videresender anmodningen til MCP-serveren, som fungerer som et interface til Concur-API'erne.
• MCP-serveren håndhæver tilladelser, logning og kontekst og kalder derefter API’et.
• Concur udfører handlingen og returnerer resultaterne til Slack.
• I denne proces udfører API’erne arbejdet, og MCP sørger for, at AI-agenterne bruger dem på en sikker måde.

Se større

Nye tendenser, der præger debatten om API kontra MCP

Der er flere faktorer, der spiller sammen, og som vil ændre den måde, virksomhederne ser på API’er og MCP:

Agentic AI-vedtagelse:

Efterhånden som flere arbejdsgange skifter til autonome agenter, vil governance flytte sig fra “bruger-til-app”-regler til “agent-til-app”-rammer.

Standardisering omkring MCP:

Konkurrerende leverandører samler sig om MCP som en fælles løsning til at forbinde AI-modeller og -værktøjer.

AI-observerbarhedsplatforme:

Dashboards, der sporer agentbeslutninger, API-kald og governance-resultater, er ved at blive uundværlige for virksomheder.

Forklaring som sikkerhed:

AI-interaktioner vil ikke kun kræve logfiler, men narrativer om, hvorfor handlinger blev foretaget.

Skift i API-design:

Selve API'erne kan udvikle sig til at inkludere “agent-venlige” metadata (tilladelser, sikre standardindstillinger, risikovurdering) indbygget.

Så vil API’er Disappear?

Nej. API’er forsvinder ikke. Faktisk bliver de stadig vigtigere, og i fremtiden vil vi se, at API’er og MCP udvikler sig i takt for at understøtte den AI-orienterede virksomhed.

MCP tilfører styring, standardisering og overvågning — men API’erne udgør stadig grundlaget. Man kan se det sådan her: MCP er færdselsloven og navigationssystemet, der gør det muligt for AI-agenter at køre sikkert på API-vejene.

Efterhånden som udbredelsen af agentbaseret AI vokser, vil virksomheder få brug for mere API'er, ikke færre.

Sådan sikrer Jitterbit MCP

Jitterbit MCP leverer en implementering i virksomhedsklasse af Model Context Protocol, som omdanner eksisterende API'er og integrationer til genbrugelige, agent-klar funktioner. Den etablerer et standardiseret kontrol lag mellem AI-modeller, agenter og virksomhedssystemer, og omdanner eksisterende integrationer og API'er til styrede, genbrugelige værktøjer.

Jitterbit MCP forener tre centrale funktioner i én samlet løsning.

Strategiske pointer

Hvor efterlader det os?

• API’er udgør stadig grundlaget. De vil ikke forsvinde — de er stadig de veje, der transporterer virksomhedens data og handlinger.
• MCP gør API’er klar til AI. Ved at regulere adfærd – ikke blot adgang – sikrer MCP, at AI-agenter kan interagere med API’er på en sikker og gennemsigtig måde.
• Udviklere bør designe API'er til fremtiden. Hvis du bygger API'er i dag, skal du tænke fremad: Hvordan vil disse API'er blive eksponeret, styret og observeret i en AI-første virksomhed?
• Der kan forventes en dobbelt investering. Virksomhederne bliver nødt til både at styrke deres API-strategier og indføre MCP-rammer for styring.
• I stedet for at gøre API’er forældede gør MCP dem »AI-first«, hvilket hjælper virksomheder med at anvende API’er sikkert i AI-drevne arbejdsgange.

Fremtiden for AI-native konnektivitet

Den næste bølge inden for virksomhedsintegration vil ikke handle om at vælge mellem API’er og MCP. Det skyldes, at den egentlige debat ikke drejer sig om API kontra MCP.

I stedet vil det handle om, hvor hurtigt organisationerne udvikler sig til at betragte API’er og MCP som komplementære lag snarere end konkurrerende valgmuligheder.

Med andre ord: API’er er ikke ved at uddø. Men virksomheder, der ikke tilpasser dem til MCP-æraen, risikerer måske at uddø.