Hva er en MCP-server? Slik fungerer MCP og MCP UI i 2026

Den 1. april 2025 publiserte Invariant Labs et verktøy som het add. Det tok to tall og returnerte summen. Beskrivelsen inneholdt også en blokk merket IMPORTANT, usynlig i klientens grensesnitt, som ba modellen lese ~/.cursor/mcp.json og ~/.ssh/id_rsa og sende begge filene ut via en ekstra parameter. Modellen adlød. Brukeren så et regnestykke.

Den demonstrasjonen er den mest nyttige introduksjonen til MCP-servere jeg kjenner, fordi den viser begge halvdelene på én gang. Protokollen fungerte akkurat slik den var tenkt: en AI-klient fant et verktøy, leste beskrivelsen og kalte det. Tillitsmodellen var den delen ingen hadde bygget ennå.

Hva en MCP-server er

En MCP-server er et program som gir AI-applikasjoner tilgang til verktøy, data og prompter via Model Context Protocol (MCP). Den offisielle dokumentasjonen definerer MCP som «en åpen kildekode-standard for å koble AI-applikasjoner til eksterne systemer.» En AI-klient som Claude, ChatGPT, Visual Studio Code eller Cursor kobler seg til serveren, spør hva den tilbyr, og kaller disse funksjonene på vegne av brukeren.

Anthropic kunngjorde MCP 25. november 2024 med seks ferdigbygde servere: Google Drive, Slack, GitHub, Git, Postgres og Puppeteer. OpenAI tok den i bruk i mars 2025. Google DeepMind fulgte i april. I desember 2025 donerte Anthropic protokollen til Agentic AI Foundation, et fond under Linux Foundation som Anthropic, Block og OpenAI grunnla sammen.

Problemet er antall forbindelser. Før MCP skrev hver AI-app sin egen GitHub-kobling, og hver leverandør bygde en kobling for hver AI-app. Ti modeller og ti verktøy kunne gi hundre integrasjoner. MCP gjør tallet til tjue: hver klient implementerer protokollen én gang, og hvert system tilbyr én server.

Tenk på det som AI-integrasjonenes container. Før containeren lastet hver havn hver last for hånd, med egne kraner og eget arbeidslag. Containeren standardiserte kassen, slik at ethvert skip, enhver kran og enhver lastebil kunne flytte enhver last. Den standardiserte ikke hva som lå i kassen, og den inspiserte aldri innholdet. MCP gjør den samme handelen. Hold fast på den andre halvdelen. Den kommer tilbake i avsnittet om sikkerhet.

Slik fungerer en MCP-server

Den gjeldende spesifikasjonen, versjon 2026-07-28, bruker JSON-RPC 2.0-meldinger mellom tre roller. Dens egen beskrivelse er tre linjer lang: verter er «LLM-applikasjoner som starter forbindelser», klienter er «koblinger inne i vertsapplikasjonen», og servere er «tjenester som leverer kontekst og funksjoner.»

Vert, klient, server

Verten er applikasjonen du skriver i: Claude Desktop, en IDE, din egen agent. Inne i den kjører én klient per serverforbindelse. Serveren sitter på den andre siden og snakker med det ekte systemet, enten det er en Postgres-database, GitHubs API eller en mappe på disken din. Verten bestemmer hva modellen ser og hva brukeren må godkjenne. Serveren bestemmer hva det underliggende systemet gjør.

1. Vert Claude Desktop · en IDE · din egen agent

   viser modellen verktøyene, ber brukeren om samtykke

2. Klient én per serverforbindelse

   snakker JSON-RPC over stdio eller Streamable HTTP

3. MCP-server verktøy · ressurser · prompter

   beskriver hva den tilbyr og utfører kallene

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

   gjør jobben

Verktøy, ressurser og prompter

En server kan tilby tre typer ting:

• Verktøy (tools) er funksjoner modellen kan kjøre: create_issue, query_orders, send_email. Hvert verktøy har et navn, en beskrivelse og et JSON Schema for input.
• Ressurser (resources) er kontekst og data som brukeren eller modellen kan lese: en fil, et databaseskjema, en post.
• Prompter (prompts) er malbaserte meldinger og arbeidsflyter brukeren kan velge, for eksempel «oppsummer denne pull requesten».

Verktøyene får mest oppmerksomhet fordi de handler. Det er også derfor de bærer mesteparten av risikoen.

Et verktøykall, steg for steg

Revisjonen 2026-07-28 gjorde MCP tilstandsløs. Det finnes ikke lenger noe initialize-håndtrykk. Hver forespørsel bærer protokollversjonen og klientens funksjoner i et _meta-felt, og servere må implementere en server/discover-metode slik at en klient kan spørre på forhånd hva de støtter. Ett enkelt verktøykall går nå slik:

1. Brukeren ber om: opprett en sak for denne feilen

2. Steg 1

   Oppdag

   • Klienten kan kalle server/discover for versjoner og funksjoner
3. Steg 2

   Hent verktøy

   • tools/list returnerer navn, beskrivelser og inputskjemaer
4. Steg 3

   Modellen velger et verktøy

   • Verten sender verktøydefinisjonene til modellen
5. Steg 4

   Brukerens samtykke

   • Ifølge spesifikasjonen må verter få uttrykkelig samtykke før de kaller et verktøy
6. Steg 5

   Kall

   • tools/call med argumenter, protokollversjon i _meta

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

   Steg 6

   Resultat

8. Resultatet går tilbake til modellen som kontekst

Steg 6 er nytt i denne revisjonen. En server som trenger mer informasjon, sender ikke lenger en egen forespørsel tilbake til klienten. Den returnerer et resultat merket input_required, klienten henter inn svaret og prøver det opprinnelige kallet på nytt. Spesifikasjonen kaller dette Multi Round-Trip Request-mønsteret.

Transporter: stdio og Streamable HTTP

Spesifikasjonen definerer to standardiserte transporter:

• stdio: klienten starter serveren som underprosess og utveksler JSON-RPC-meldinger, én per linje, via standard input og output. Slik kjører de fleste lokale servere, og det betyr at serveren kjører på maskinen din med dine rettigheter.
• Streamable HTTP: hver melding er en HTTP POST til ett enkelt endepunkt, og svarene kommer tilbake som et JSON-objekt eller en hendelsesstrøm som hører til akkurat den forespørselen. Slik kjører eksterne servere som driftes andre steder.

Den eldre HTTP+SSE-transporten er formelt avviklet. Revisjonen 2026-07-28 fjernet også økter på protokollnivå og Mcp-Session-Id-headeren. En server som trenger tilstand på tvers av kall, lager nå sitt eget håndtak og får det tilbake som et vanlig verktøyargument.

Autorisasjon

Autorisasjon er valgfritt i MCP, og det gjelder bare HTTP. Over stdio sier spesifikasjonen at servere heller skal hente påloggingsinformasjon fra miljøet. Over HTTP fungerer en beskyttet MCP-server som OAuth 2.1-ressursserver. Den må publisere OAuth Protected Resource Metadata (RFC 9728) slik at klienter kan finne autorisasjonsserveren. Klienter må oppgi nøyaktig hvilken server et token er ment for (RFC 8707-ressursindikatorer). Servere må avvise ethvert token som ikke er utstedt til dem, og sikkerhetsveiledningen kaller «token passthrough», altså å sende en klients token uendret videre til et API lenger ned i kjeden, uttrykkelig forbudt.

Den siste regelen betyr mer enn den ser ut til. En server som videresender ethvert token den mottar, blir en proxy for alle som har et.

Hva MCP UI tilfører: servere som returnerer et grensesnitt

Tekstsvar slutter å fungere i det øyeblikket en bruker må sammenligne førti rader, justere et skjema med tolv felt eller godkjenne en rekke endringer én etter én. «MCP UI» er navnet folk søker etter løsningen med: en server returnerer et interaktivt grensesnitt som vises inne i AI-klienten, ved siden av samtalen.

Statusen bør beskrives presist. Ideen startet med MCP-UI, et fellesskapsprosjekt. OpenAI bygde en lignende mekanisme i Apps SDK. MCP-prosjektet foreslo en felles standard med begge 21. november 2025, og 26. januar 2026 ble MCP Apps den første offisielle MCP-utvidelsen. MCP-UI-pakkene følger nå standarden og er fortsatt et sted å prøve ut forbedringer.

MCP UI betyr altså i dag MCP Apps. Det er offisielt, og det er en utvidelse, ikke kjerneprotokoll. Utvidelser er noe man velger å ta i bruk: både klient og server må støtte dem, og dokumentasjonen sier rett ut at «støtten varierer fra klient til klient.» Dokumentasjonen for MCP Apps lister Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam og Archestra.AI som verter med støtte. En server der verktøyene returnerer UI, må fortsatt fungere for en klient som bare viser tekst.

Mekanisk gjenbruker det MCPs egne byggeklosser:

1. Beskrivelsen av et verktøy inneholder en _meta.ui.resourceUri som peker til en ui://-ressurs.
2. Verten henter ressursen, en HTML-side med skriptene sine, og kan forhåndslaste den før verktøyet kalles.
3. Verten viser den i en sandkasset iframe som ikke kan lese den overordnede siden, informasjonskapslene eller lagringen.
4. Appen og verten snakker sammen via postMessage i en JSON-RPC-dialekt av MCP. Appen kan be om verktøykall, og verten bestemmer hvilke den tillater.

Kostnaden er reell. Du leverer nå en nettfrontend inne i noen andres applikasjon, med en content security policy du må deklarere, visningsregler du ikke styrer, og en tekstversjon for hver vert som ignorerer den. Gevinsten er at godkjenningsarbeid ikke lenger er en chatlogg. Dokumentasjonens egen liste over gode bruksområder slutter med «godkjenning av utleggsrapporter, gjennomgang av kodeendringer eller sortering av saker», og det er den ærlige kjernen: MCP UI er best på beslutninger, ikke på pynt.

Et skrivebeskyttet Tajo-eksempel

Tajo sin Alto MCP-flate har query_contacts, som søker i kontakter lagret i tilkoblet arbeidsområde. Søk etter én eksisterende kontakt med email og se ID, status for emailsamtykke og tidspunkt for siste observasjon. Det separate get_contact_topic_status leser personens emneabonnementer.

Dette er lesinger fra arbeidsområdet. De henter ikke et ferskt bilde fra leverandøren, starter ikke synkronisering og sender ikke meldinger. De beviser heller ikke at alle leverandørkoblinger er aktive. Undersøk manglende eller gamle data ved kilden. Et tomt svar beviser ikke at personen mangler i Brevo.

Bruk Tajos MCP-dokumentasjon til å koble til en støttet klient og se verktøyene arbeidsområdet faktisk gir tilgang til. Et interaktivt panel kan hjelpe hvis verten støtter MCP Apps. Tekstsvaret må likevel forklare resultatet.

Et verktøykall er ikke en varig synkronisering

Gjentatt synkronisering trenger også tidsplan, stabil postidentitet, lagret fremdrift, beslutninger om nye forsøk og oversikt over fullførte skrivinger. Appen som utfører jobben må sørge for dette. MCP standardiserer tilgang til verktøy, men en oppføring i listen leverer ikke disse reglene.

Etter tidsavbrudd kan en lesing vanligvis gjentas. En sending eller betaling kan allerede ha skjedd. Bevar kjøringsloggen og avstem resultatet før et nytt forsøk. Modellens sikkerhet gir ikke tillatelse og gjør ikke gjentakelsen trygg.

Brevo API-guiden viser målskriving for en konkret kontaktvei. Reverse ETL-guiden forklarer når beregnede felt trenger en egen vedlikeholdt synkronisering.

Sikkerhetsregningen følger med protokollen

Innvendingen fortjener å bli gjengitt i sin helhet: «MCP gir en sannsynlighetsbasert modell en liste med funksjoner som kan slette data og sende e-post, og stoler så på tekst skrevet av fremmede for å beskrive dem. Det er ikke en integrasjonsstandard. Det er et forsyningskjedeangrep med en spesifikasjon.» Det meste av det stemmer. Spesifikasjonen er enig i premisset. Sikkerhetsavsnittet sier at verktøy «representerer vilkårlig kodekjøring og må behandles med passende forsiktighet», at verktøybeskrivelser «bør anses som upålitelige, med mindre de kommer fra en betrodd server», og at MCP «ikke kan håndheve disse sikkerhetsprinsippene på protokollnivå.»

Her er historikken så langt:

• Tool poisoning (forgiftede verktøybeskrivelser). Avsløringen fra Invariant Labs i april 2025, add-verktøyet ovenfor. Samme innlegg beskrev rug pulls, der en server endrer beskrivelsen av et verktøy etter at du har godkjent det, og shadowing, der én ondsinnet server omskriver modellens oppførsel overfor en betrodd server.
• Kompromitterte lokale servere. I juli 2025 offentliggjorde JFrog CVE-2025-6514 i mcp-remote versjon 0.0.5 til 0.1.15, som lot en ondsinnet server kjøre kommandoer på brukerens maskin. Samme sommer rammet CVE-2025-49596 Anthropics egen MCP Inspector, som ble levert uten autentisering som standard.
• Oppblåste scopes. De offisielle beste praksisene for sikkerhet setter navn på mønsteret: tokens som får files:* eller admin:* fra start, fordi en server listet opp alle scopes og klienten ba om alle sammen.
• Offisiell bekymring. I mai 2026 sa amerikanske National Security Agency at MCPs «raske spredning har løpt fra utviklingen av sikkerhetsmodellen.»

Der innvendingen tar feil, er konklusjonen. Løsningen var aldri å slutte å koble modeller til systemer. Teamene gjorde det allerede, med rå API-nøkler limt inn i prompter og skript, helt uten revisjonsspor. Løsningen er å behandle en MCP-server som enhver annen avhengighet med privilegier:

• Installer bare servere fra kilder du ville betrodd de samme påloggingsopplysningene også utenfor MCP.
• Velg heller eksterne servere med OAuth og smale scopes enn lokale binærfiler som holder på langlivede nøkler.
• Krev menneskelig godkjenning for hver skriving, og logg hvem som godkjente hva.
• Lås serverversjoner, og gå gjennom på nytt når beskrivelsen av et verktøy endres.
• Eksponer verktøy formet etter oppgaven, ikke et helt API. En modell kan ikke misbruke et delete-endepunkt som aldri ble eksponert.

Protokollen standardiserte kassen. Å inspisere lasten er fortsatt din jobb.

Bygg en MCP-server eller bruk en eksisterende

Offentlige kataloger som mcp.so samler servere bygget av communityet, og mange SaaS-leverandører publiserer sine egne. Brevo leverer for eksempel en MCP-server som også er delt opp i enkeltservere, slik at en agent kan få tilgang til kontakter uten kampanjer. Valget handler mindre om innsats enn om hvem som skal eie formen på verktøyene.

Hvilken MCP-server skal agenten din bruke?

1. Leverandøren publiserer en server som dekker oppgaven

   Bruk leverandørens server

   Den følger API-et, og leverandøren vedlikeholder den.

2. Ett system, men du trenger færre eller tryggere handlinger

   Bruk den, nedskalert

   Gi minimale scopes og eksponer bare verktøygruppene agenten trenger.

3. Interne data eller et system uten server

   Bygg en liten server

   Noen få oppgaveformede verktøy oppå ditt eget API, med din egen autentisering.

4. Oppgaven spenner over to eller flere systemer

   Bygg eller velg et styrt lag

   Ett sett verktøy, samtykkeregler og revisjonshistorikk på tvers av alle.

Å bygge en enkel server er den lette delen. Med et offisielt SDK er en fungerende stdio-server med ett verktøy en ettermiddags arbeid. Kostnaden kommer senere: OAuth for HTTP-versjonen, avviklinger (revisjonen 2026-07-28 avviklet Roots, Sampling og Logging, samt Dynamic Client Registration) og den løpende jobben med å skrive verktøybeskrivelser som en modell leser riktig. Å pakke inn et API med ett verktøy per endepunkt er den vanligste feilen. Hver verktøybeskrivelse er tekst modellen må lese og vurdere, så en kort liste med oppgaveformede verktøy slår hele API-flaten.

MCP, API-er, integrasjoner og iPaaS

MCP erstatter ikke API-er. Nesten hver eneste MCP-server er et skall rundt et API. API-et er fortsatt der jobben gjøres, med sine egne rate limits, sin egen datamodell og sine egne særheter. MCP endrer hvem som kan kalle det: en modell, mens den kjører, som velger kallet ut fra en beskrivelse, i stedet for en utvikler som hardkoder det på forhånd.

Det skillet trekker en tydelig grense mot de to andre tingene MCP forveksles med:

• Integrasjoner og iPaaS (de viktigste plattformene sammenlignes her) flytter data etter en tidsplan eller en trigger, deterministisk, uansett om noen sitter i en chat. En nattlig synkronisering av 40 000 ordrer til et CRM bør ikke avhenge av at en modell bestemmer seg for å gjøre 40 000 verktøykall.
• Reverse ETL sender modellerte data fra et datavarehus tilbake til operative verktøy. Hva reverse ETL er og når det passer er et eget tema, og det er en pipeline, ikke en samtale.
• MCP er for øyeblikkene når en person eller en agent trenger å spørre, undersøke eller handle på tvers av disse systemene, ved behov.

Feilen går begge veier. Noen team bygger MCP-servere for massesynkronisering og får trege, dyre pipelines som ikke kan gjentas. Andre team bygger nøye integrasjoner og gir så AI-assistenten sin en rå API-nøkkel for å spørre dem, og får en ustyrt bakdør.

For en støttet integrasjon bør den varige jobben og verktøyene som undersøker den dele en tydelig tillatelsesgrense. Kontroller koblingen, tillatte handlinger og registrerte resultater for akkurat denne flyten. Integrasjonsdokumentasjonen skiller oppsett fra veier som fortsatt trenger bevis i produksjon. MCP kan vise separate godkjente verktøy; listen beviser ikke at gjentatt synkronisering eller alle kontroller er aktive.

På 22 måneder gikk MCP fra seks referanseservere til et Linux Foundation-prosjekt som Claude, ChatGPT, VS Code og Cursor alle snakker. Å koble en modell til et system er nå den billige delen. Å avgjøre hva den får gjøre der, er jobben.