MCP, Model Context Protocol, presenteras ofta som det självklara sättet att koppla AI-agenter till dina system. Men om du redan har ett REST API är det en onödig omväg.
AI-agenter kan redan prata med REST API:er
En AI-agent med terminalåtkomst, som till exempel Claude Code, kan anropa ett REST-API direkt. Genom att använda verktyg som curl eller olika HTTP-bibliotek kan agenten skicka förfrågningar precis som om det vore vilket annat terminalkommando som helst. Det innebär att ett väl definierat REST-API med en OpenAPI-specifikation erbjuder samma funktionalitet som ett MCP-anrop.
AI-agenter har oftast full förståelse kring hur de ska generera ett korrekt curl kommando eftersom curl är vedertaget verktyg som finns i alla operativsystem. Skulle en agent göra ett misstag, kan de själva köra curl --help för att få hjälp med strukturen på kommandot.
Dessutom har REST API:et fördelen att ha existerat i några årtionden, och har således fått ett ecosystem av verktyg och hjälpmedel. Andra fördelar inkluderar HTTP caching, lastbalansering, autentisering, skalning med mera. Detta är så klart inte omöjligt att uppnå med MCP, men varför spendera tid att bygga en ny infrastruktur när den redan finns för ditt API?
En vanlig missuppfattning
En vanlig missuppfattning är att en MCP-server ersätter backendlogiken. Det gör den inte. Du måste ändå skriva all logik som hanterar förfrågningarna. MCP lägger bara ett extra lager ovanpå det du redan har, vilket innebär fler beroenden att underhålla, mer kod att felsöka, och ett större angreppsmönster utan att du får något tillbaka som REST API:et inte redan ger. Genom att tillhandahålla ett REST API och en MCP-server, krävs det underhåll av två separata serverarkitekturer och processer.
MCP servrar erbjuder verktygsidentifiering (tool discovery) som gör det enkelt för en MCP klient att hitta relevanta verktyg. Ett exempel på ett verktyg i en finansiell MCP-server skulle kunna vara “hämta dagens fakturor”. Detta verktyg kommer returnera fakturorna till klienten som sedan kan göra sin AI-analys. Men om du redan har ett väldefinierat REST API tillgängligt, då är dina HTTP ändpunkter dina verktyg, och din API dokumentation agerar som verktygsidentifiering.
API dokumentationen kan distribueras som en AI skill (en prompt som beskriver API:t) eller kan man erbjuda en HTTP ändpunkt som returnerar kortfattad dokumentation som gör det enkelt för en AI-agent att dynamiskt förstå hur den ska använda API:t.
Verktygsexponering är ett argument som ofta lyfts fram till MCP:s fördel, men i praktiken har MCP haft påtagliga problem med just verktygsidentifiering och namnkollisioner när många verktyg exponeras samtidigt. REST har inga sådana inbyggda begränsningar.
Sandlådan
En AI-agent med åtkomst till operativsystemet bör alltid köras i en så kallad sandlåda, oavsett om den kommunicerar via MCP eller direkt mot ett REST API med curl. Detta är för att undvika allvarliga konsekvenser där en agent av misstag, eller till följd av en skadlig instruktion, raderar viktiga filer eller utför oönskade åtgärder. En sandlåda är oftast en virtuell miljö som endast får tillgång till specifika kataloger i grundsystemet. Om agenten gör ett allvarligt misstag i sandlådan kan man enkelt skapa en ny.
Det finns fler säkerhetsåtgärder att ta hänsyn till, som strikt nätverksfiltrering och behörighetsbegränsningar, men det är ett ämne för en egen artikel.
Angreppsytan ökar
Genom att installera populära MCP servrar ökar man den totala angreppsytan genom tredje-parts beroenden och exponerad funktionalitet.
Det har uppstått flera sårbarhetsklasser i MCP servrar, till exempel verktygsförgiftning (tool poisoning), där en MCP-server gömmer skadliga instruktioner i verktygets metadata.
Dessa angrepsmetoder kan tekniskt sätt genomföras via ett REST API, beroende på hur det är strukturerat. Skillnaden för ett REST API är att en användare kan spara API dokumentationen lokalt, inspektera den, och sedan hänvisa AI-agenten till dokumentationen. Om REST API:et förändras kommer AI-agenten med störst sannolikhet misslyckas med sina anrop och då kan man inspektera förändringen. En MCP-server kan i det tysta förändra verktygsdefinitioner eller metadata, utan att användaren lägger märke till det, och inkludera skadliga instruktioner till AI-agenten. Det är denna dynamiska och osynliga förändringen som bland annat ökar den totala angreppsytan.
En MCP-server kan via sampling begära att klienten skickar din agents kontextfönster till en extern LLM. Det innebär att känslig information som interna instruktioner, tidigare konversationer eller affärsdata, kan lämna din miljö utan att du märker det.
Däremot går det att reducera risken som en skadlig MCP-server utgör. Men om man redan erbjuder ett REST API, varför introducera nya risker som måste hanteras?
Tokenkostnad
Varje extra informationsutbyte kostar pengar. MCP verktygsmanifest, metadata, sessionsförhandling och i synnerhet sampling förbrukar tokens vid varje interaktion. Genom att köra direkt anrop med till exempel curl, undviker man extra information och kan direkt filtrera på den information man efterfrågar. I en verksamhet där AI-agenter körs dygnet runt adderas dessa små extrakostnader ihop till betydande summor.
När en MCP-server exponerar ett stort antal verktyg får klienten hela listan vid uppstart, vilket belastar kontextfönstret och ökar tokenkostnaden ytterligare. Agenten kan också ha svårt att välja rätt verktyg när många liknar varandra.
MCP användare har länge klagat på kostnaden och svårigheterna för MCP klienter att hitta rätt verktyg när en MCP-server exponerar mängder med verktyg. Det har resulterat i flera förslag och förändringar i MCP protokollet, till exempel:
Detta kommer optimera tokenanvändningen i MCP protokollet och minska kostnaden för användare.
När är MCP faktiskt motiverat?
MCP är motiverat när dina användare är icke-tekniska, redan använder en GUI-baserad agentklient, och inte har något annat sätt att ansluta till din tjänst. Om dina användare är tekniska eller agenter som körs i en terminal räcker ett REST API.
Tre saker att tänka på när man väljer MCP-server och klient:
Använd en klient som upptäcker när verktygsdefinitioner ändras och varnar dig. Om din klient accepterar ändringar tyst bör du inte lita på den.
Kräv alltid human in the loop vid sampling. Sampling innebär att MCP-servern kan trigga LLM-anrop på din bekostnad, utan att du nödvändigtvis märker det.
Var medveten om tokenkostnaden. Om MCP-servern inte optimerar verktygsidentifiering betalar du för metadata du inte behöver, varje anrop.