Hvad er en MCP-server? Sådan virker MCP og MCP UI i 2026

Den 1. april 2025 udgav Invariant Labs et værktøj ved navn add. Det tog to tal og returnerede summen. Beskrivelsen indeholdt også en blok markeret IMPORTANT, usynlig i klientens brugerflade, som bad modellen læse ~/.cursor/mcp.json og ~/.ssh/id_rsa og sende begge filer ud via en ekstra parameter. Modellen adlød. Brugeren så et regnestykke.

Den demonstration er den mest brugbare introduktion til MCP-servere, jeg kender, fordi den viser begge halvdele på én gang. Protokollen virkede præcis som tiltænkt: en AI-klient fandt et værktøj, læste beskrivelsen og kaldte det. Tillidsmodellen var den del, ingen havde bygget endnu.

Hvad en MCP-server er

En MCP-server er et program, der giver AI-applikationer adgang til værktøjer, data og prompts via Model Context Protocol (MCP). Den officielle dokumentation definerer MCP som »en open source-standard til at forbinde AI-applikationer med eksterne systemer.« En AI-klient som Claude, ChatGPT, Visual Studio Code eller Cursor forbinder sig til serveren, spørger, hvad den tilbyder, og kalder de funktioner på brugerens vegne.

Anthropic annoncerede MCP den 25. november 2024 med seks færdigbyggede servere: Google Drive, Slack, GitHub, Git, Postgres og Puppeteer. OpenAI tog den i brug i marts 2025. Google DeepMind fulgte i april. I december 2025 donerede Anthropic protokollen til Agentic AI Foundation, en fond under Linux Foundation, som Anthropic, Block og OpenAI stiftede sammen.

Problemet er antallet af forbindelser. Før MCP skrev hver AI-app sin egen forbindelse til GitHub, og hver leverandør byggede én forbindelse til hver AI-app. Ti modeller og ti værktøjer kunne give op til hundrede integrationer. MCP gør det til tyve: hver klient implementerer protokollen én gang, og hvert system udstiller én server.

Tænk på det som AI-integrationernes skibscontainer. Før containeren lastede hver havn hver last i hånden, med egne kraner og eget sjak. Containeren standardiserede kassen, så ethvert skib, enhver kran og enhver lastbil kunne flytte enhver last. Den standardiserede ikke, hvad der lå i kassen, og den kontrollerede aldrig indholdet. MCP er den samme handel. Hold fast i den anden halvdel. Den vender tilbage i afsnittet om sikkerhed.

Sådan virker en MCP-server

Den nuværende specifikation, version 2026-07-28, bruger JSON-RPC 2.0-beskeder mellem tre roller. Dens egen beskrivelse fylder tre linjer: værter er »LLM-applikationer, der starter forbindelser«, klienter er »connectors inde i værtsapplikationen«, og servere er »tjenester, der leverer kontekst og funktioner.«

Vært, klient, server

Værten er den applikation, du skriver i: Claude Desktop, en IDE, din egen agent. Inde i den kører én klient pr. serverforbindelse. Serveren sidder på den anden side og taler med det rigtige system, uanset om det er en Postgres-database, GitHubs API eller en mappe på din disk. Værten bestemmer, hvad modellen ser, og hvad brugeren skal godkende. Serveren bestemmer, hvad det underliggende system gør.

1. Vært Claude Desktop · en IDE · din egen agent

   viser modellen værktøjerne, beder brugeren om samtykke

2. Klient én pr. serverforbindelse

   taler JSON-RPC over stdio eller Streamable HTTP

3. MCP-server værktøjer · ressourcer · prompts

   beskriver, hvad den tilbyder, og udfører kaldene

4. Underliggende system database · SaaS-API · lokale filer

   gør arbejdet

Værktøjer, ressourcer og prompts

En server kan tilbyde tre slags ting:

• Værktøjer (tools) er funktioner, modellen kan udføre: create_issue, query_orders, send_email. Hvert værktøj har et navn, en beskrivelse og et JSON Schema for sit input.
• Ressourcer (resources) er kontekst og data, som brugeren eller modellen kan læse: en fil, et databaseskema, en post.
• Prompts er skabelonbeskeder og arbejdsgange, brugeren kan vælge, for eksempel »opsummer denne pull request«.

Værktøjerne får mest opmærksomhed, fordi de handler. Det er også derfor, de bærer det meste af risikoen.

Et værktøjskald, trin for trin

Revisionen fra 2026-07-28 gjorde MCP tilstandsløs. Der er ikke længere noget initialize-handshake. Hver forespørgsel bærer sin protokolversion og klientens funktioner i et _meta-felt, og servere skal implementere en server/discover-metode, så en klient på forhånd kan spørge, hvad de understøtter. Et enkelt værktøjskald forløber nu sådan her:

1. Brugeren beder om: opret en sag for denne fejl

2. Trin 1

   Opdag

   • Klienten kan kalde server/discover for versioner og funktioner
3. Trin 2

   Hent værktøjer

   • tools/list returnerer navne, beskrivelser og inputskemaer
4. Trin 3

   Modellen vælger et værktøj

   • Værten giver værktøjsdefinitionerne videre til modellen
5. Trin 4

   Brugerens samtykke

   • Ifølge specifikationen skal værter have udtrykkeligt samtykke, før de kalder et værktøj
6. Trin 5

   Kald

   • tools/call med argumenter, protokolversion i _meta

7. Mangler der input? Serveren returnerer input_required, og klienten prøver igen med svarene

   Trin 6

   Resultat

8. Resultatet går tilbage til modellen som kontekst

Trin 6 er nyt i denne revision. En server, der har brug for flere oplysninger, sender ikke længere sin egen forespørgsel tilbage til klienten. Den returnerer et resultat markeret input_required, klienten indsamler svaret og prøver det oprindelige kald igen. Specifikationen kalder det Multi Round-Trip Request-mønsteret.

Transporter: stdio og Streamable HTTP

Specifikationen definerer to standardiserede transporter:

• stdio: klienten starter serveren som underproces og udveksler JSON-RPC-beskeder, én pr. linje, over standard input og output. Sådan kører de fleste lokale servere, og det betyder, at serveren kører på din maskine med dine rettigheder.
• Streamable HTTP: hver besked er en HTTP POST til ét endpoint, og svarene kommer tilbage som et JSON-objekt eller en hændelsesstrøm, der hører til den enkelte forespørgsel. Sådan kører fjernservere, der hostes eksternt.

Den ældre HTTP+SSE-transport er formelt udfaset. Revisionen fra 2026-07-28 fjernede også sessioner på protokolniveau og Mcp-Session-Id-headeren. En server, der skal huske tilstand mellem kald, laver nu selv et håndtag og får det tilbage som et almindeligt værktøjsargument.

Autorisation

Autorisation er valgfri i MCP og gælder kun for HTTP. Over stdio siger specifikationen, at servere i stedet skal hente legitimationsoplysninger fra miljøet. Over HTTP fungerer en beskyttet MCP-server som OAuth 2.1-ressourceserver. Den skal udgive OAuth Protected Resource Metadata (RFC 9728), så klienter kan finde dens autorisationsserver. Klienter skal angive præcis, hvilken server et token er til (RFC 8707-ressourceindikatorer). Servere skal afvise ethvert token, der ikke er udstedt til dem, og sikkerhedsvejledningen kalder »token passthrough«, altså at sende en klients token uændret videre til et API længere nede i kæden, for udtrykkeligt forbudt.

Den sidste regel betyder mere, end den ser ud til. En server, der videresender ethvert token, den modtager, bliver en proxy for alle, der har et.

Hvad MCP UI tilføjer: servere, der returnerer en brugerflade

Tekstsvar holder op med at virke i det øjeblik, en bruger skal sammenligne fyrre rækker, rette en formular med tolv felter eller godkende en række ændringer én ad gangen. »MCP UI« er det navn, folk søger efter løsningen under: en server returnerer en interaktiv brugerflade, der vises inde i AI-klienten, ved siden af samtalen.

Status kræver præcision. Ideen begyndte med MCP-UI, et fællesskabsprojekt. OpenAI byggede en lignende mekanisme i sit Apps SDK. MCP-projektet foreslog en fælles standard med begge den 21. november 2025 og udgav MCP Apps den 26. januar 2026 som den første officielle MCP-udvidelse. MCP-UI-pakkerne implementerer nu standarden og bruges fortsat til at afprøve forbedringer.

MCP UI betyder altså i dag MCP Apps. Det er officielt, og det er en udvidelse, ikke kerneprotokol. Udvidelser er noget, man vælger til: både klient og server skal understøtte dem, og dokumentationen siger ligeud, at »understøttelsen varierer fra klient til klient.« Dokumentationen til MCP Apps nævner Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam og Archestra.AI som værter med understøttelse. En server, hvis værktøjer returnerer UI, skal stadig virke for en klient, der kun viser tekst.

Mekanisk genbruger det MCP’s egne byggesten:

1. Et værktøjs beskrivelse indeholder en _meta.ui.resourceUri, der peger på en ui://-ressource.
2. Værten henter ressourcen, en HTML-side med scripts, og kan forhåndsindlæse den, før værktøjet kaldes.
3. Værten viser den i en sandboxet iframe, som ikke kan læse forældresiden, dens cookies eller dens lager.
4. Appen og værten taler sammen via postMessage i en JSON-RPC-dialekt af MCP. Appen kan bede om værktøjskald, og værten bestemmer, hvilke den tillader.

Omkostningen er reel. Du leverer nu en webfrontend inde i en andens applikation, med en content security policy, du skal deklarere, visningsregler, du ikke styrer, og en tekstudgave til hver vært, der ignorerer den. Gevinsten er, at godkendelsesarbejde ikke længere er et chatforløb. Dokumentationens egen liste over gode anvendelser slutter med »godkendelse af udgiftsrapporter, gennemgang af kodeændringer eller sortering af issues«, og det er den ærlige kerne: MCP UI er bedst til beslutninger, ikke til pynt.

Et skrivebeskyttet Tajo-eksempel

Tajo’s Alto MCP-flade har query_contacts, som søger i kontakter gemt i det tilsluttede arbejdsområde. Søg efter én eksisterende kontakt via email, og se det returnerede id, status for emailsamtykke og tidspunkt for seneste observation. Værktøjet get_contact_topic_status læser kontaktens emneabonnementer.

Det er læsninger fra arbejdsområdet. De henter ikke et nyt billede direkte fra leverandøren, starter ingen synkronisering og sender ingen besked. De viser heller ikke, at alle connectors er aktive. Undersøg manglende eller gamle data ved kilden. Et tomt resultat beviser ikke, at personen ikke findes i Brevo.

Brug Tajos MCP-dokumentation til at forbinde en understøttet klient og se de værktøjer, som dit godkendte arbejdsområde faktisk udstiller. Et interaktivt panel kan lette gennemgangen, hvis værten understøtter MCP Apps. Tekstresultatet skal stadig forklare udfaldet.

Et værktøjskald er ikke en varig synkronisering

En tilbagevendende synkronisering behøver også en tidsplan, stabil postidentitet, gemt fremdrift, beslutninger om gentagelser og en fortegnelse over fuldførte skrivninger. Det er ansvar for den app, der udfører arbejdet. MCP standardiserer adgang til værktøjer; en værktøjsliste leverer ikke disse forretningsregler.

Efter timeout kan en læsning normalt gentages. En afsendelse eller betaling kan allerede være udført. Bevar udførelsesloggen, og afstem udfaldet før næste forsøg. En models sikkerhed giver ikke tilladelse og gør ikke gentagelsen sikker.

Se guiden til Brevos API for destinationsskrivningen i en konkret kontaktvej. Reverse ETL-guiden forklarer, hvornår beregnede felter fortjener deres egen vedligeholdte synkronisering.

Sikkerhedsregningen følger med protokollen

Indvendingen fortjener at blive fremført i sin helhed: »MCP giver en sandsynlighedsbaseret model en liste over funktioner, der kan slette data og sende e-mails, og stoler så på tekst skrevet af fremmede til at beskrive dem. Det er ikke en integrationsstandard. Det er et supply chain-angreb med en specifikation.« Det meste af det er korrekt. Specifikationen er enig i præmissen. Dens sikkerhedsafsnit siger, at værktøjer »repræsenterer vilkårlig kodekørsel og skal behandles med passende forsigtighed«, at værktøjsbeskrivelser »bør betragtes som upålidelige, medmindre de kommer fra en betroet server«, og at MCP »ikke kan håndhæve disse sikkerhedsprincipper på protokolniveau.«

Her er historikken indtil nu:

• Tool poisoning (forgiftede værktøjsbeskrivelser). Invariant Labs’ afsløring fra april 2025, add-værktøjet ovenfor. Samme indlæg beskrev rug pulls, hvor en server ændrer et værktøjs beskrivelse, efter du har godkendt det, og shadowing, hvor én ondsindet server omskriver modellens adfærd over for en betroet server.
• Kompromitterede lokale servere. I juli 2025 offentliggjorde JFrog CVE-2025-6514 i mcp-remote, version 0.0.5 til 0.1.15, som lod en ondsindet server køre kommandoer på brugerens maskine. Samme sommer ramte CVE-2025-49596 Anthropics egen MCP Inspector, som blev leveret uden godkendelse som standard.
• Oppustede scopes. De officielle best practices for sikkerhed navngiver mønsteret: tokens, der på forhånd får files:* eller admin:*, fordi en server listede alle scopes, og klienten bad om dem alle.
• Officiel bekymring. I maj 2026 sagde den amerikanske National Security Agency, at MCP’s »hurtige udbredelse er løbet fra udviklingen af dens sikkerhedsmodel.«

Hvor indvendingen tager fejl, er i konklusionen. Løsningen var aldrig at holde op med at forbinde modeller til systemer. Teams gjorde det allerede, med rå API-nøgler indsat i prompts og scripts, helt uden revisionsspor. Løsningen er at behandle en MCP-server som enhver anden afhængighed med privilegier:

• Installér kun servere fra kilder, du også ville betro de samme legitimationsoplysninger uden for MCP.
• Foretræk fjernservere med OAuth og snævre scopes frem for lokale binærfiler med langtidsholdbare nøgler.
• Kræv menneskelig godkendelse af hver skrivning, og log, hvem der godkendte hvad.
• Lås serverversioner fast, og gennemgå igen, når et værktøjs beskrivelse ændrer sig.
• Udstil værktøjer formet efter opgaven, ikke et helt API. En model kan ikke misbruge et delete-endpoint, der aldrig blev udstillet.

Protokollen standardiserede kassen. At inspicere lasten er stadig din opgave.

Byg en MCP-server, eller brug en eksisterende

Offentlige kataloger som mcp.so samler servere bygget af communityet, og mange SaaS-leverandører udgiver deres egne. Brevo leverer for eksempel en MCP-server, som også er delt op i enkelte servere, så en agent kan få adgang til kontakter uden kampagner. Valget handler mindre om indsats og mere om, hvem der skal eje værktøjernes form.

Hvilken MCP-server skal din agent bruge?

1. Leverandøren udgiver en server, der dækker opgaven

   Brug leverandørens server

   Den følger API’et, og leverandøren vedligeholder den.

2. Ét system, men du har brug for færre eller sikrere handlinger

   Brug den, men skær ned

   Giv minimale scopes, og udstil kun de værktøjsgrupper, agenten har brug for.

3. Interne data eller et system uden server

   Byg en lille server

   Nogle få opgaveformede værktøjer oven på dit eget API, med din egen godkendelse.

4. Opgaven spænder over to eller flere systemer

   Byg eller vælg et styret lag

   Ét sæt værktøjer, samtykkeregler og revisionshistorik på tværs af dem alle.

At bygge en simpel server er den lette del. Med et officielt SDK er en fungerende stdio-server med ét værktøj en eftermiddags arbejde. Regningen kommer senere: OAuth til HTTP-versionen, udfasninger (revisionen fra 2026-07-28 udfasede Roots, Sampling og Logging samt Dynamic Client Registration) og det løbende arbejde med at skrive værktøjsbeskrivelser, som en model læser korrekt. At pakke et API ind med ét værktøj pr. endpoint er den mest udbredte fejl. Hver værktøjsbeskrivelse er tekst, modellen skal læse og afveje, så en kort liste af opgaveformede værktøjer slår hele API-overfladen.

MCP, API’er, integrationer og iPaaS

MCP erstatter ikke API’er. Næsten alle MCP-servere er en indpakning omkring et API. API’et er stadig dér, arbejdet sker, med sine egne rate limits, sin egen datamodel og sine egne særheder. MCP ændrer, hvem der kan kalde det: en model, mens den kører, der vælger kaldet ud fra en beskrivelse, i stedet for en udvikler, der hardkoder det på forhånd.

Den forskel trækker en klar grænse over for de to andre ting, MCP bliver forvekslet med:

• Integrationer og iPaaS (de vigtigste platforme sammenlignes her) flytter data efter en tidsplan eller en trigger, deterministisk, uanset om nogen sidder i en chat. En natlig synkronisering af 40.000 ordrer til et CRM bør ikke afhænge af, at en model beslutter sig for at lave 40.000 værktøjskald.
• Reverse ETL skubber modellerede data fra et datavarehus tilbage til de operationelle værktøjer. Hvad reverse ETL er, og hvornår det passer, er et emne for sig, og det er en pipeline, ikke en samtale.
• MCP er til de øjeblikke, hvor en person eller en agent skal spørge, undersøge eller handle på tværs af de systemer, efter behov.

Fejlen går begge veje. Nogle teams bygger MCP-servere til massesynkronisering og får langsomme, dyre pipelines, der ikke kan gentages. Andre teams bygger omhyggelige integrationer og giver så deres AI-assistent en rå API-nøgle til at forespørge dem, og de får en ustyret bagdør.

For en understøttet integration bør det varige job og værktøjerne til at undersøge det dele en tydelig tilladelsesgrænse. Bekræft connector, tilladte handlinger og registrerede udfald for netop denne arbejdsgang. Integrationsdokumentationen skelner opsætningsvejledning fra veje, der stadig kræver produktionsbevis. MCP kan udstille særskilte godkendte værktøjer; at de er listet, beviser hverken en tilbagevendende synkronisering eller aktive kontroller.

På 22 måneder gik MCP fra seks referenceservere til et Linux Foundation-projekt, som Claude, ChatGPT, VS Code og Cursor alle taler. At forbinde en model til et system er nu den billige del. At afgøre, hvad den må gøre der, er arbejdet.