Den som bygger AI-agenter känner igen problemet: för varje funktion i en ansluten tjänst måste ett eget verktyg definieras. Söka, skapa, ändra och radera en kalenderpost – det blir snabbt fyra separata byggstenar, och det bara för en enda tjänst. Med många anslutningar växer underhållsarbetet i motsvarande grad. Model Context Protocol (MCP) går en annan väg: det standardiserar hur en språkmodell kommunicerar med en tjänst – och minskar antalet nödvändiga byggstenar drastiskt. Det här inlägget sammanfattar konceptet och ett konkret praktiskt exempel med n8n.
- MCP standardiserar hur en språkmodell förstår kontexten hos en tjänst – alltså vad den kan och hur man tilltalar den.
- I stället för att koppla in varje enskild funktion separat räcker en MCP-server (framför tjänsten) och en MCP-klient (i agenten).
- Agenten klarar sig med två steg: lista funktioner (List Tools) och köra funktioner (Execute Tool).
- I n8n går det att bygga efter med en miljövariabel, en community-node och två MCP-klientverktyg.
- MCP är en ung teknik: det finns kända säkerhetsinvändningar – i produktionsmiljöer är försiktighet påkallad.

Vad MCP egentligen löser
Grundidén med Model Context Protocol ligger i namnet: en språkmodell ska förstå kontexten hos en applikation. Konkret betyder det: vad kan den här applikationen? Vad är den till för? Och hur utför jag åtgärder i den?
Klassiskt kopplar man vid agentbygge in varje verktyg för sig – varje funktion är en egen byggsten. I Google Calendar till exempel: ett verktyg för att söka poster, ett för att uppdatera, ett för att radera, ett för att skapa. Fyra funktioner för en tjänst. Hos komplexa agenter med många anslutna tjänster summerar det sig snabbt till dussintals byggstenar.
Server, klient och det enhetliga schemat
MCP arbetar med två roller:
- MCP-server: placerar sig framför den egentliga tjänsten (t.ex. Airbnb eller Google Calendar) och beskriver hur man kan interagera med tjänsten.
- MCP-klient: sitter i agenten och hämtar respektive anropar serverns funktioner.
I den nuvarande implementationen – till exempel i n8n – räcker två steg i stället för många enskilda verktyg:
- List Tools (lista): agenten frågar servern vilka funktioner som finns tillgängliga.
- Execute Tool (köra): agenten anropar en konkret funktion med passande parametrar.
Avgörande är det enhetliga schemat. Oavsett vilken tjänst som ligger bakom: svaret på en List-Tools-förfrågan är alltid uppbyggt på samma sätt. Det innehåller per funktion namnet, en beskrivning och ett schema med de tillåtna parametrarna. Innehåll och parametrar skiljer sig från tjänst till tjänst – strukturen förblir konstant. Det är precis det protokollet föreskriver och standardiserar.
Ett exempel med Airbnb-verktyget
Frågar man agenten vilka möjligheter Airbnb-verktyget erbjuder hämtar den funktionslistan själv via List-Tools-verktyget. Tillbaka kommer bland annat:
- Airbnb Search: sökning efter erbjudanden med filter och paginering – till exempel plats, incheckningsdatum och utcheckningsdatum, antal vuxna, barn, spädbarn och husdjur samt prisintervall.
- Airbnb Listing Details: detaljerad information om ett bestämt erbjudande via dess listing-ID.
Agenten behövde inte få något förutbestämt – den skaffade själv fram de tillgängliga funktionerna, deras beskrivningar och parameterschemat. I schemat ser man till exempel ett textfält location (stad, region etc.), datumfälten för in- och utcheckning, antalet vuxna samt lägsta och högsta pris.
Ställer man sedan en konkret fråga – till exempel ett boende i Bangkok för sex personer för högst 50 euro per natt – arbetar agenten i två steg: den anropar först List Tools (den har inte kommit ihåg något, eftersom inget minne är aktivt), identifierar de nödvändiga parametrarna utifrån schemat och genomför sökningen via Execute Tool. Resultatet – till exempel ett boende med tre sängar för cirka 35 euro per natt – kommer tillbaka, och det med bara två tillagda verktyg. Skulle Airbnb erbjuda fler funktioner, till exempel för att hantera egna annonser, skulle de kunna täckas av samma schema utan att fler byggstenar behöver definieras.
Så bygger du MCP i n8n
Följande steg visar uppsättningen med Airbnb som exempel. Det lämpar sig bra att testa med, eftersom ingen API-nyckel behövs.
- Sätt miljövariabeln: sätt
N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGEtilltrue. Det ger community-nodes åtkomst till verktyg. Vid en Docker-installation (t.ex. på en Hetzner-server) lägger du in det i avsnittetenvironmentidocker-compose-filen och startar om instansen. - Skapa en AI-agent: skapa en AI-agent och lägg in en modell (i videon GPT-4.1 Mini).
- Installera community-noden: under Settings → Community Nodes installerar du paketet
n8n-nodes-mcpoch bekräftar varningen om installation av ogranskad kod från offentliga källor. - Lägg till MCP-klientverktyget: sök efter „MCP“ via plustecknet vid Tools. Obs: förväxla det inte med n8n:s eget MCP Client Tool – community-varianten känns igen på boxsymbolen och är för närvarande mer omfattande.
- Skapa inloggningsuppgifter: som anslutningstyp finns Command Line, Server-Sent Events och HTTP Streamable att välja mellan. I exemplet blir det Command Line. Rätt värden står i respektive MCP-servers repository i avsnittet om installation. För Airbnb: kommandot
npx, argumenten inlagda steg för steg –-y, paketet@openbnb/mcp-server-airbnboch valfritt--ignore-robots-txt.
Om robots.txt: alternativet
--ignore-robots-txtförbigår åtkomstreglerna för en webbplats. För en demo är det försvarbart – i produktionsmiljöer bör du respektera robots.txt hos respektive tjänst.
Att ställa in de båda operationerna
Därefter behöver du två MCP-klientverktyg med olika operationer:
- List Tools: döp verktyget till t.ex. „Airbnb List Tools“ och ange som beskrivning att det används för att hämta alla tillgängliga Airbnb-verktyg. Ett testklick (Execute Step) bör returnera den bekanta funktionslistan med namn, beskrivning och schema.
- Execute Tool: ett andra MCP-klientverktyg med operationen Execute Tool. Beskrivning: för att köra Airbnb-verktyg, som kan listas via List-Tools-verktyget. Verktygsnamnet skickar du som en expression, så att agenten själv avgör vilken funktion den anropar; verktygsparametrarna lämnar du fria så att den bestämmer dem själv.
Efter uppstädning och sparande går agenten att testa – till exempel på nytt med Bangkok-frågan. Den hämtar funktionslistan, ger den tillbaka till modellen, bestämmer sig för sökningen och levererar passande boenden. Exakt beteendet från konceptdelen, nu i ditt eget arbetsflöde.
Bortom n8n – och ett ord om säkerheten
MCP begränsar sig inte till automatiseringsplattformar. Även skrivbordsprogram som Claude Desktop går att koppla till MCP-servrar. Därmed kan man i chatten delegera uppgifter till lokalt installerade program – ett ofta citerat exempel är styrningen av 3D-programmet Blender via MCP, där en person utan Blender-kunskaper skapar renderingar. MCP-servern körs då lokalt, medan själva språkmodellen fortfarande går via molntjänsten.
Trots all entusiasm gäller: MCP är en ung utveckling. Det finns redan säkerhetsinvändningar, och säkerhetsluckor har hittats. Just i produktionsmiljöer bör tekniken hanteras med försiktighet – det lönar sig att följa den fortsatta utvecklingen innan man bygger kritiska processer på den.
Slutsats
Model Context Protocol är ett pragmatiskt sätt att standardisera: en språkmodell lär sig själv via en MCP-server vad en tjänst kan och hur man tilltalar den – i stället för att varje funktion definieras i förväg. För komplexa AI-agenter betyder det märkbart färre byggstenar och mindre underhåll; i n8n-exemplet räcker två steg: lista och köra. Ansatsen är övertygande, men fortfarande ung. Den som provar den bör börja med okritiska tjänster och ta de öppna säkerhetsfrågorna på allvar i produktionsmiljöer.
Källa: Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch), på tyska – YouTube-kanalen Philip Thomas.
