Vad är en MCP-server? Så fungerar MCP och MCP UI 2026

Den 1 april 2025 publicerade Invariant Labs ett verktyg som hette add. Det tog två tal och returnerade summan. Beskrivningen innehöll också ett block märkt IMPORTANT, osynligt i klientens gränssnitt, som sa åt modellen att läsa ~/.cursor/mcp.json och ~/.ssh/id_rsa och skicka ut båda filerna via en extra parameter. Modellen lydde. Användaren såg en addition.

Den demonstrationen är den mest användbara introduktionen till MCP-servrar jag känner till, eftersom den visar båda halvorna på en gång. Protokollet fungerade exakt som det var tänkt: en AI-klient hittade ett verktyg, läste beskrivningen och anropade det. Förtroendemodellen var den del som ingen hade byggt än.

Vad en MCP-server är

En MCP-server är ett program som ger AI-applikationer tillgång till verktyg, data och promptar via Model Context Protocol (MCP). Den officiella dokumentationen definierar MCP som ”en standard med öppen källkod för att koppla AI-applikationer till externa system.” En AI-klient som Claude, ChatGPT, Visual Studio Code eller Cursor ansluter till servern, frågar vad den erbjuder och anropar de funktionerna åt användaren.

Anthropic presenterade MCP den 25 november 2024 med sex färdiga servrar: Google Drive, Slack, GitHub, Git, Postgres och Puppeteer. OpenAI anslöt i mars 2025. Google DeepMind följde i april. I december 2025 skänkte Anthropic protokollet till Agentic AI Foundation, en fond under Linux Foundation som Anthropic, Block och OpenAI grundade tillsammans.

Problemet är antalet kopplingar. Före MCP skrev varje AI-app sin egen GitHub-anslutning, och varje leverantör byggde en koppling för varje AI-app. Tio modeller och tio verktyg kunde kräva hundra integrationer. MCP gör det till tjugo: varje klient implementerar protokollet en gång och varje system exponerar en server.

Se det som AI-integrationernas container. Före containern lastade varje hamn varje last för hand, med egna kranar och eget arbetslag. Containern standardiserade lådan, så att vilket fartyg, vilken kran och vilken lastbil som helst kunde flytta vilken last som helst. Den standardiserade inte vad som låg i lådan, och den inspekterade aldrig innehållet. MCP gör samma affär. Kom ihåg den andra halvan. Den kommer tillbaka i avsnittet om säkerhet.

Så fungerar en MCP-server

Den nuvarande specifikationen, version 2026-07-28, använder JSON-RPC 2.0-meddelanden mellan tre roller. Dess egen beskrivning är tre rader lång: värdar är ”LLM-applikationer som initierar anslutningar”, klienter är ”kopplingar inuti värdapplikationen” och servrar är ”tjänster som tillhandahåller kontext och funktioner.”

Värd, klient, server

Värden är applikationen du skriver i: Claude Desktop, en IDE, din egen agent. Inuti den körs en klient per serveranslutning. Servern sitter på andra sidan och pratar med det riktiga systemet, oavsett om det är en Postgres-databas, GitHubs API eller en mapp på din disk. Värden bestämmer vad modellen ser och vad användaren måste godkänna. Servern bestämmer vad det underliggande systemet gör.

1. Värd Claude Desktop · en IDE · din egen agent

   visar modellen verktygen, ber användaren om samtycke

2. Klient en per serveranslutning

   pratar JSON-RPC över stdio eller Streamable HTTP

3. MCP-server verktyg · resurser · promptar

   beskriver vad den erbjuder och kör anropen

4. Underliggande system databas · SaaS-API · lokala filer

   gör jobbet

Verktyg, resurser och promptar

En server kan erbjuda tre sorters saker:

• Verktyg (tools) är funktioner som modellen kan köra: create_issue, query_orders, send_email. Varje verktyg har ett namn, en beskrivning och ett JSON Schema för sina indata.
• Resurser (resources) är kontext och data som användaren eller modellen kan läsa: en fil, ett databasschema, en post.
• Promptar (prompts) är mallade meddelanden och arbetsflöden som användaren kan välja, till exempel ”sammanfatta den här pull requesten”.

Verktygen får mest uppmärksamhet eftersom de agerar. Det är också därför de bär det mesta av risken.

Ett verktygsanrop, steg för steg

Revisionen 2026-07-28 gjorde MCP tillståndslöst. Det finns ingen initialize-handskakning längre. Varje anrop bär sin protokollversion och klientens funktioner i ett _meta-fält, och servrar måste implementera en server/discover-metod så att en klient i förväg kan fråga vad de stöder. Ett enskilt verktygsanrop går nu till så här:

1. Användaren ber: skapa ett ärende för den här buggen

2. Steg 1

   Upptäck

   • Klienten kan anropa server/discover för versioner och funktioner
3. Steg 2

   Lista verktyg

   • tools/list returnerar namn, beskrivningar och indatascheman
4. Steg 3

   Modellen väljer ett verktyg

   • Värden skickar verktygsdefinitionerna till modellen
5. Steg 4

   Användarens samtycke

   • Enligt specen måste värdar få uttryckligt samtycke innan de anropar ett verktyg
6. Steg 5

   Anrop

   • tools/call med argument, protokollversion i _meta

7. Saknas indata? Servern returnerar input_required och klienten försöker igen med svaren

   Steg 6

   Resultat

8. Resultatet går tillbaka till modellen som kontext

Steg 6 är nytt i den här revisionen. En server som behöver mer information skickar inte längre ett eget anrop tillbaka till klienten. Den returnerar ett resultat märkt input_required, klienten samlar in svaret och försöker det ursprungliga anropet igen. Specen kallar det Multi Round-Trip Request-mönstret.

Transporter: stdio och Streamable HTTP

Specen definierar två standardiserade transporter:

• stdio: klienten startar servern som underprocess och utbyter JSON-RPC-meddelanden, ett per rad, via standard in och standard ut. Så körs de flesta lokala servrar, och det betyder att servern körs på din dator med dina behörigheter.
• Streamable HTTP: varje meddelande är en HTTP POST till en enda endpoint, och svaren kommer tillbaka som ett JSON-objekt eller en händelseström som hör till just det anropet. Så körs fjärrservrar som hostas externt.

Den äldre HTTP+SSE-transporten är formellt utfasad. Revisionen 2026-07-28 tog också bort sessioner på protokollnivå och Mcp-Session-Id-headern. En server som behöver tillstånd mellan anrop skapar nu ett eget handtag och får tillbaka det som ett vanligt verktygsargument.

Auktorisering

Auktorisering är valfri i MCP och gäller bara HTTP. Över stdio säger specen att servrar i stället ska hämta inloggningsuppgifter från miljön. Över HTTP fungerar en skyddad MCP-server som OAuth 2.1-resursserver. Den måste publicera OAuth Protected Resource Metadata (RFC 9728) så att klienter kan hitta dess auktoriseringsserver. Klienter måste ange exakt vilken server en token är avsedd för (RFC 8707-resursindikatorer). Servrar måste avvisa varje token som inte utfärdats för dem, och säkerhetsvägledningen pekar ut ”token passthrough”, att skicka en klients token oförändrad vidare till ett API längre ned i kedjan, som uttryckligen förbjudet.

Den sista regeln väger tyngre än den ser ut. En server som vidarebefordrar vilken token den än får blir en proxy för alla som har en.

Vad MCP UI tillför: servrar som returnerar ett gränssnitt

Textsvar slutar fungera i samma stund som en användare behöver jämföra fyrtio rader, justera ett formulär med tolv fält eller godkänna en rad ändringar en i taget. ”MCP UI” är namnet folk söker på för lösningen: en server returnerar ett interaktivt gränssnitt som visas inuti AI-klienten, bredvid konversationen.

Statusen behöver precision. Idén började med MCP-UI, ett gemenskapsprojekt. OpenAI byggde en liknande mekanism i Apps SDK. MCP-projektet föreslog en gemensam standard tillsammans med båda den 21 november 2025 och publicerade MCP Apps den 26 januari 2026 som den första officiella MCP-utökningen. MCP-UI-paketen följer nu standarden och används fortsatt för att prova förbättringar.

MCP UI betyder alltså i dag MCP Apps. Det är officiellt, och det är ett tillägg, inte kärnprotokoll. Tillägg väljer man till: både klient och server måste stödja dem, och dokumentationen säger rakt ut att ”stödet varierar mellan klienter.” Dokumentationen för MCP Apps listar Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam och Archestra.AI som värdar med stöd. En server vars verktyg returnerar UI måste fortfarande fungera för en klient som bara visar text.

Mekaniskt återanvänder det MCP:s egna byggstenar:

1. Ett verktygs beskrivning innehåller en _meta.ui.resourceUri som pekar på en ui://-resurs.
2. Värden hämtar resursen, en HTML-sida med sina skript, och kan förladda den innan verktyget anropas.
3. Värden visar den i en sandlådad iframe som inte kan läsa den överordnade sidan, dess cookies eller dess lagring.
4. Appen och värden pratar via postMessage i en JSON-RPC-dialekt av MCP. Appen kan begära verktygsanrop, och värden bestämmer vilka den tillåter.

Kostnaden är verklig. Du levererar nu ett webbgränssnitt inuti någon annans applikation, med en content security policy som du måste deklarera, visningsregler du inte styr över och en textversion för varje värd som ignorerar det. Vinsten är att godkännandearbete inte längre är en chattlogg. Dokumentationens egen lista över bra användningsområden slutar med ”godkänna utläggsrapporter, granska kodändringar eller sortera ärenden”, och det är den ärliga kärnan: MCP UI är bäst på beslut, inte på dekoration.

Ett skrivskyddat Tajo-exempel

Tajo har query_contacts i sitt Alto MCP-gränssnitt. Verktyget söker bland kontakter som finns i den anslutna arbetsytan. Sök upp en befintlig kontakt via e-post och granska ID, samtycke för e-post och tidpunkt för senaste observation. Verktyget get_contact_topic_status läser kontaktens ämnesprenumerationer.

Det här är läsningar i arbetsytan. De hämtar ingen färsk ögonblicksbild från leverantören, startar ingen synkronisering och skickar inget meddelande. De visar inte heller att alla leverantörsanslutningar fungerar. Undersök saknade eller gamla uppgifter vid källan. Ett tomt resultat bevisar inte att personen saknas i Brevo.

Använd Tajos MCP-dokumentation för att ansluta en stödd klient och se vilka verktyg din behöriga arbetsyta faktiskt exponerar. En interaktiv panel kan underlätta när värden stöder MCP Apps. Textresultatet måste ändå förklara vad som hände.

Ett verktygsanrop är inte en varaktig synkronisering

Återkommande synkronisering behöver dessutom schema, stabil postidentitet, sparade framsteg, beslut om nya försök och en logg över färdiga skrivningar. Appen som utför arbetet ansvarar för detta. MCP standardiserar verktygsåtkomst; att ett verktyg listas ger inte affärsreglerna.

Efter en timeout kan en läsning oftast upprepas. Ett utskick eller en betalning kan redan ha skett. Spara körningsloggen och stäm av resultatet före nästa försök. Modellens säkerhet ger ingen behörighet och gör inte försöket säkert.

Brevo API-guiden beskriver målskrivning för en konkret kontaktväg. Reverse ETL-guiden förklarar när beräknade fält behöver en egen underhållen synkronisering.

Säkerhetsnotan följer med protokollet

Invändningen förtjänar att återges i sin helhet: ”MCP ger en probabilistisk modell en lista med funktioner som kan radera data och skicka mejl, och litar sedan på text skriven av främlingar för att beskriva dem. Det är ingen integrationsstandard. Det är en supply chain-attack med en specifikation.” Det mesta av det stämmer. Specen håller med om premissen. Dess säkerhetsavsnitt säger att verktyg ”innebär godtycklig kodkörning och måste hanteras med lämplig försiktighet”, att verktygsbeskrivningar ”bör betraktas som opålitliga, om de inte kommer från en betrodd server”, och att MCP ”inte kan upprätthålla dessa säkerhetsprinciper på protokollnivå.”

Så här ser facit ut hittills:

• Tool poisoning (förgiftade verktygsbeskrivningar). Invariant Labs avslöjande från april 2025, add-verktyget ovan. Samma inlägg beskrev rug pulls, där en server ändrar ett verktygs beskrivning efter att du godkänt det, och shadowing, där en illasinnad server skriver om modellens beteende gentemot en betrodd server.
• Komprometterade lokala servrar. I juli 2025 offentliggjorde JFrog CVE-2025-6514 i mcp-remote version 0.0.5 till 0.1.15, som lät en illasinnad server köra kommandon på användarens dator. Samma sommar drabbade CVE-2025-49596 Anthropics egen MCP Inspector, som levererades utan autentisering som standard.
• Uppblåsta scopes. De officiella säkerhetsrekommendationerna sätter namn på mönstret: tokens som får files:* eller admin:* från start, eftersom en server listade alla scopes och klienten begärde dem allihop.
• Officiell oro. I maj 2026 sa amerikanska National Security Agency att MCP:s ”snabba spridning har sprungit ifrån utvecklingen av dess säkerhetsmodell.”

Där invändningen går fel är slutsatsen. Lösningen var aldrig att sluta koppla modeller till system. Teamen gjorde det redan, med råa API-nycklar inklistrade i promptar och skript, helt utan granskningsspår. Lösningen är att behandla en MCP-server som vilket annat beroende med privilegier som helst:

• Installera bara servrar från källor du skulle anförtro samma inloggningsuppgifter även utanför MCP.
• Välj hellre fjärrservrar med OAuth och snäva scopes än lokala binärer som håller långlivade nycklar.
• Kräv mänskligt godkännande för varje skrivning, och logga vem som godkände vad.
• Lås serverversioner, och granska igen när ett verktygs beskrivning ändras.
• Exponera verktyg formade efter uppgiften, inte ett helt API. En modell kan inte missbruka en delete-endpoint som aldrig exponerades.

Protokollet standardiserade lådan. Att inspektera lasten är fortfarande ditt jobb.

Bygg en MCP-server eller använd en befintlig

Offentliga kataloger som mcp.so samlar servrar byggda av communityn, och många SaaS-leverantörer publicerar egna. Brevo levererar till exempel en MCP-server som också är uppdelad i enskilda servrar, så att en agent kan få tillgång till kontakter utan kampanjer. Beslutet handlar mindre om arbetsinsats och mer om vem som ska äga verktygens form.

Vilken MCP-server ska din agent använda?

1. Leverantören publicerar en server som täcker uppgiften

   Använd leverantörens server

   Den följer API:et och leverantören underhåller den.

2. Ett system, men du behöver färre eller säkrare åtgärder

   Använd den, nedskalad

   Ge minimala scopes och exponera bara de verktygsgrupper agenten behöver.

3. Intern data eller ett system utan server

   Bygg en liten server

   Några uppgiftsformade verktyg ovanpå ditt eget API, med din egen autentisering.

4. Uppgiften spänner över två eller fler system

   Bygg eller välj ett styrt lager

   En uppsättning verktyg, samtyckesregler och granskningshistorik över dem alla.

Att bygga en enkel server är den lätta delen. Med ett officiellt SDK är en fungerande stdio-server med ett verktyg en eftermiddags jobb. Kostnaden kommer senare: OAuth för HTTP-versionen, utfasningar (revisionen 2026-07-28 fasade ut Roots, Sampling och Logging samt Dynamic Client Registration) och det löpande jobbet att skriva verktygsbeskrivningar som en modell läser rätt. Att kapsla in ett API med ett verktyg per endpoint är det vanligaste misstaget. Varje verktygsbeskrivning är text som modellen måste läsa och väga, så en kort lista med uppgiftsformade verktyg slår hela API-ytan.

MCP, API:er, integrationer och iPaaS

MCP ersätter inte API:er. Nästan varje MCP-server är ett skal runt ett. API:et är fortfarande där jobbet görs, med sina egna rate limits, sin egen datamodell och sina egna egenheter. MCP ändrar vem som kan anropa det: en modell, under körning, som väljer anropet utifrån en beskrivning, i stället för en utvecklare som hårdkodar det i förväg.

Den skillnaden drar en tydlig gräns mot de två andra saker MCP förväxlas med:

• Integrationer och iPaaS (de viktigaste plattformarna jämförs här) flyttar data enligt ett schema eller en trigger, deterministiskt, oavsett om någon sitter i en chatt. En nattlig synkronisering av 40 000 ordrar till ett CRM ska inte hänga på att en modell bestämmer sig för att göra 40 000 verktygsanrop.
• Reverse ETL skickar modellerad data från ett datalager tillbaka till operativa verktyg. Vad reverse ETL är och när det passar är ett eget ämne, och det är en pipeline, inte en konversation.
• MCP är till för de stunder när en person eller en agent behöver fråga, granska eller agera i de systemen, vid behov.

Misstaget går åt båda hållen. Vissa team bygger MCP-servrar för massynkronisering och får långsamma, dyra pipelines som inte går att upprepa. Andra team bygger noggranna integrationer och ger sedan sin AI-assistent en rå API-nyckel för att fråga dem, och får en ostyrd bakdörr.

För en stödd integration bör det varaktiga jobbet och verktygen som granskar det dela en tydlig behörighetsgräns. Kontrollera anslutning, tillåtna åtgärder och registrerade resultat för just det arbetsflödet. Integrationsdokumentationen skiljer installationsråd från vägar som ännu saknar bevis i produktion. MCP kan visa separata godkända verktyg; en lista bevisar inte att återkommande synkronisering eller alla kontroller är aktiva.

På 22 månader gick MCP från sex referensservrar till ett Linux Foundation-projekt som Claude, ChatGPT, VS Code och Cursor alla talar. Att koppla en modell till ett system är nu den billiga delen. Att bestämma vad den får göra där är jobbet.