Model Context Protocol: Bygg din första MCP-server idag

Model Context Protocol (MCP) är en öppen standard som ger AI-modeller ett universellt sätt att ansluta till externa verktyg, datakällor och tjänster. Istället för att skriva anpassad integrationskod för varje modell-verktyg-kombination skriver du en MCP-server och varje kompatibel modell kan använda den. Anthropic skapade MCP i slutet av 2024, Linux Foundation styr det nu, och OpenAI, Google och resten av det agentiska AI-ekosystemet har antagit det. Här är allt du behöver förstå, bygga och driftsätta med MCP.

MCP i ett nötskal

Om du vill ha den snabba versionen innan du dyker in i 6 000 ord med detaljer, här är den.

Nu ska vi packa upp var och en av dessa, med start på vad MCP faktiskt är och problemet som gjorde det nödvändigt.

Vad är Model Context Protocol?

Model Context Protocol är ett öppet, JSON-RPC-baserat protokoll som standardiserar hur AI-modeller upptäcker och interagerar med externa verktyg och data. Tänk på det som HTTP för AI-integrationer -- ett gemensamt språk som vilken modell och vilket verktyg som helst kan tala.

Du har förmodligen hört USB-C-analogin, och den är användbar till en viss punkt: innan USB-C behövde varje enhet sin egen kabel. MCP gör samma sak för AI, men analogin underskattar det. USB-C transporterar bara data och ström. MCP transporterar verktygsdefinitioner, dataåtkomstmönster, återanvändbara promptmallar och låter till och med servrar begära kompletteringar från modellen. Det är ett rikare protokoll än en kabelmetafor antyder.

M x N-problemet som MCP löser

Utan MCP kräver att ansluta M modeller till N verktyg M x N anpassade integrationer. Säg att du stöder 5 LLM:er (Claude, GPT-4, Gemini, Llama, Mistral) och behöver dem att komma åt 10 verktyg (GitHub, Postgres, Slack, Jira och så vidare). Det är 50 skräddarsydda integrationslager, vart och ett med sin egen autentisering, felhantering och dataformatering.

Med MCP implementerar varje modell MCP-klientprotokollet en gång, och varje verktyg implementerar en MCP-server en gång. Nu är det 5 + 10 = 15 implementationer istället för 50. Lägga till en ny modell? Den fungerar omedelbart med alla 10 verktyg. Lägga till ett nytt verktyg? Alla 5 modeller kan använda det.

En kort historia om MCP

Anthropic open-sourcade MCP i november 2024 tillsammans med SDK:er för Python och TypeScript plus kopplingar för Claude Desktop. Adoptionen gick snabbt. OpenAI lade till MCP-stöd till ChatGPT i mars 2025. Google följde för Gemini i april 2025. I december 2025 donerade Anthropic MCP till Linux Foundations nya Agentic AI Foundation (AAIF), medgrundad med Block och OpenAI, vilket gör MCP till en leverantörsneutral standard med branschövergripande styrning.

Vad MCP INTE är:

• Inte en modell eller ett AI-ramverk (det är ett protokoll, som HTTP)
• Inte en ersättare för LangChain eller LlamaIndex (de är orkestreringslager; MCP sitter under dem)
• Inte begränsat till Anthropic eller Claude (det är modellagnostiskt by design)
• Inte detsamma som function calling (mer om det i jämförelseavsnittet)

Hur fungerar MCP? Djupdykning i arkitekturen

MCP har tre roller, och att blanda ihop dem är det vanligaste nybörjarmisstaget. Låt oss klargöra skillnaden.

Host, Klient och Server -- Vad är skillnaden?

Här är ett konkret exempel: du ber Claude Desktop att kolla dina öppna GitHub-pull requests. Claude Desktop är hosten. Dess inbyggda MCP-klient öppnar en anslutning till GitHub MCP-servern. Servern anropar GitHub-API:et, hämtar dina PR:er och returnerar resultaten till klienten, som skickar dem till modellen.

En enda host kan köra flera klienter, var och en ansluten till en annan server. Det är så Claude Desktop kan komma åt GitHub, din Postgres-databas och Slack samtidigt -- tre separata MCP-servrar, tre separata klientanslutningar, en host.

Hur meddelanden flödar (JSON-RPC 2.0)

All MCP-kommunikation använder JSON-RPC 2.0 -- ett lättviktigt förfrågan/svar-protokoll. Så här ser ett tools/list-utbyte ut på nätet:

// Klientförfrågan: "Vilka verktyg har du?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Serversvar: ett verktyg tillgängligt
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Hämta aktuellt väder för en stad",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Modellen läser dessa verktygsdefinitioner, bestämmer när de ska anropas baserat på användarens förfrågan, och klienten skickar en tools/call-förfrågan tillbaka till servern med lämpliga argument.

Anslutningens livscykel

Varje MCP-session följer samma livscykel:

1. Initialisera -- klienten skickar kapabiliteter, servern svarar med sina egna
2. Kapabilitetsförhandling -- båda sidor enas om stödda funktioner (verktyg, resurser, prompter, sampling)
3. Redo -- anslutningen är aktiv; förfrågningar flödar i båda riktningarna
4. Förfrågningar/svar -- tools/call, resources/read, osv.
5. Stängning -- ren frånkoppling

Det här handslaget säkerställer framåtkompatibilitet. Om en server lägger till en ny primitiv ignorerar äldre klienter den graciöst istället för att krascha.

MCP-primitiver: Verktyg, Resurser, Prompter och Sampling

MCP definierar fyra primitiver, och att förstå vem som kontrollerar var och en är nyckeln till att designa bra MCP-servrar.

Verktyg (modellkontrollerade)

Verktyg är funktioner som modellen kan anropa. Servern deklarerar dem med ett namn, en beskrivning och en JSON Schema-inmatningsdefinition. Modellen läser dessa definitioner och, när en användares förfrågan kräver det, bestämmer den sig för att anropa verktyget.

// Klienten skickar en tools/call-förfrågan
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Stockholm" }
  }
}

Om du har använt OpenAIs function calling kommer verktyg att kännas bekanta -- men de är standardiserade för varje MCP-kompatibel modell.

Resurser (applikationskontrollerade)

Resurser är skrivskyddade dataendpoints. Till skillnad från verktyg bestämmer modellen inte att hämta en resurs på egen hand -- hostapplikationen eller användaren bifogar explicit resurser till konversationskontexten. Tänk på dem som GET-endpoints: postgres://mydb/users/schema, file://docs/api-reference.md. Se även vår guide till context engineering.

Resurser stöder prenumerationer via resources/subscribe, så klienten kan meddelas när data ändras.

Prompter (användarkontrollerade)

Prompter är återanvändbara mallar som en MCP-server exponerar. En code_review-prompt kan acceptera en filsökväg och generera en strukturerad granskningsförfrågan. Användaren (eller host-UI:t) triggar prompter explicit -- de anropas inte automatiskt av modellen.

Sampling (serverinitierat) -- Avancerat

Här är primitiven som de flesta guider hoppar över. Sampling låter servern be klienten att generera en komplettering med LLM:en. Det inverterar det vanliga flödet: istället för att modellen anropar ett verktyg, anropar verktyget modellen.

Varför? Agentiska loopar. Föreställ dig en MCP-server som behandlar supportärenden. Den läser ärendet (en resurs), använder sampling/createMessage för att be modellen om en sammanfattning, sedan använder den sammanfattningen för att dirigera ärendet via ett verktyg. Servern orkestrerar ett flerstegs arbetsflöde som utnyttjar modellens intelligens.

Sampling styrs av hostapplikationen -- användaren måste godkänna det, och hosten kontrollerar vad servern kan begära. Det förhindrar okontrollerade loopar och upprätthåller mänsklig tillsyn.

Bygg din första MCP-server: Python och TypeScript sida vid sida

Nog med teori. Låt oss bygga en fungerande MCP-server som exponerar ett get_weather-verktyg. Jag visar både Python och TypeScript så att du kan jämföra utvecklarupplevelsen och välja det stack som passar ditt projekt.

Python med FastMCP

FastMCP är den officiella Python SDK:n på hög nivå. Den hanterar all protokollinstallation så att du kan fokusera på din verktygslogik.

# Installera FastMCP
pip install fastmcp

# weather_server.py
from fastmcp import FastMCP

mcp = FastMCP("Vädersserver")

@mcp.tool()
def get_weather(city: str) -> str:
    """Hämta aktuellt väder för en stad."""
    # I produktion, anropa ett riktigt väder-API här
    weather_data = {
        "Stockholm": "Molnigt, 8°C",
        "Tokyo": "Soligt, 22°C",
        "New York": "Regnigt, 8°C",
    }
    return weather_data.get(city, f"Ingen data för {city}")

if __name__ == "__main__":
    mcp.run()

Det är allt -- 15 rader. FastMCP härleder verktygets inmatningsschema från Python-typannoteringar och docstring. Inget JSON Schema-boilerplate.

TypeScript med officiell SDK

TypeScript SDK:n (@modelcontextprotocol/sdk) är lite mer explicit men ger dig full kontroll över schemadefinitioner.

# Installera SDK och Zod för schemavalidering
npm install @modelcontextprotocol/sdk zod

// weather-server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "Väderserver",
  version: "1.0.0",
});

server.tool(
  "get_weather",
  "Hämta aktuellt väder för en stad",
  { city: z.string() },
  async ({ city }) => {
    const weatherData: Record<string, string> = {
      Stockholm: "Molnigt, 8°C",
      Tokyo: "Soligt, 22°C",
      "New York": "Regnigt, 8°C",
    };
    return {
      content: [
        { type: "text", text: weatherData[city] ?? `Ingen data för ${city}` },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

TypeScript-versionen använder Zod-scheman istället för typannoteringar och returnerar strukturerade innehållsblock. Mer utförlig, men typsäkerheten är utmärkt.

Anslut till Claude Desktop

För att koppla in någon av servrarna i Claude Desktop, lägg till den i din claude_desktop_config.json:

{
  "mcpServers": {
    "weather-python": {
      "command": "python",
      "args": ["weather_server.py"],
      "cwd": "/sökväg/till/ditt/projekt"
    },
    "weather-typescript": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "cwd": "/sökväg/till/ditt/projekt"
    }
  }
}

Starta om Claude Desktop och båda väderservrarna visas i verktygslistan. Fråga "Hur är vädret i Stockholm?" och modellen anropar ditt get_weather-verktyg automatiskt.

Testa med MCP Inspector

Innan du kopplar din server till en host, testa den i isolation med MCP Inspector:

npx @modelcontextprotocol/inspector python weather_server.py

Inspector öppnar ett webb-UI där du kan se upptäckta verktyg, anropa dem manuellt och inspektera JSON-RPC-meddelanden som går fram och tillbaka. Det är det bästa felsökningsverktyget i MCP-ekosystemet -- använd det tidigt och ofta.

MCP-transporter: stdio för utveckling, Streamable HTTP för produktion

MCP-meddelanden behöver ett sätt att resa mellan klient och server. Det är transportlagret, och att välja rätt spelar roll.

stdio fungerar genom att starta MCP-servern som en underprocess och kommunicera via stdin/stdout. Det är vad du använde i handledningen ovan -- inga portar, ingen TLS, ingen autentisering behövs. Perfekt för utveckling och enskilt-användar lokala verktyg.

Streamable HTTP är produktionstransporten, tillagd i 2025-specuppdateringen. Klienter skickar vanliga HTTP POST-förfrågningar till servern. Servern kan svara synkront eller öppna en SSE-ström för längre operationer. Det är tillståndslösvänligt, fungerar bakom lastbalanserare och stöder standard HTTP-autentisering.

Om du ser äldre handledningar som nämner "HTTP+SSE" som två separata transporter (en för att skicka, en för att ta emot), det är det föråldrade tillvägagångssättet. Streamable HTTP konsoliderar båda till en enda, renare mekanism.

Beslutet är enkelt: använd stdio när du utvecklar lokalt, byt till streamable-http när du driftsätter för andra.

// Byta från stdio till Streamable HTTP i TypeScript
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

const transport = new StreamableHTTPServerTransport({ port: 3001 });
await server.connect(transport);

MCP vs Function Calling vs REST API:er -- När man använder vad

Det här är frågan som dyker upp i varje MCP-diskussion, så låt oss lösa det med en direkt jämförelse. Du kan också vara intresserad av Claude Code vs Cursor vs Copilot-jämförelse.

När function calling räcker

Om du har färre än 5 verktyg och använder en modell är function calling enklare. Du definierar dina verktygscheman inline med varje API-anrop, modellen returnerar funktionsnamnet och argumenten, och du kör dem i din applikationskod. Ingen server att köra, inget protokoll att lära sig. För en chatbot som kontrollerar orderstatus och letar upp FAQ:er är function calling fullt tillräckligt.

När MCP är värt det

MCP motiverar sin komplexitet när:

• Du stöder flera LLM:er och inte vill skriva om verktygsdefinitioner för varje leverantör
• Du behöver verktygsupptäckt -- modellen kan fråga vad som finns tillgängligt istället för att du hårdkodar scheman
• Du vill ha resurser och prompter, inte bara verktygsanrop
• Du bygger AI-agenter som koordinerar autonomt och behöver ett standardiserat integrationslager
• Ditt team växer och olika ingenjörer bygger olika verktyg -- MCP låter dem arbeta oberoende

Slutsats: MCP vinner när du behöver standardiserad, multi-modell verktygsåtkomst. Function calling vinner för enkla, en-modell-användningsfall. REST API:er är fortfarande rätt val för traditionell tjänst-till-tjänst-kommunikation som inte involverar en LLM.

MCP-ekosystemet 2026: Vem stöder det och vad finns tillgängligt

MCP gick från ett Anthropic-sidoprojekt till en industristandard på under 18 månader. Här är läget.

Vilka LLM:er stöder MCP?

Populära MCP-servrar värda att känna till

Linux Foundations AAIF-tillkännagivande citerade 10 000+ aktiva servrar och 97 miljoner månatliga SDK-nedladdningar vid MCP:s donation i december 2025. Ekosystemet är inte längre experimentellt -- det är produktionsklar.

MCP Apps är en ny primitiv introducerad i januari 2026. Det låter servrar tillhandahålla interaktiva UI-komponenter som renderas inuti hostapplikationen. Fortfarande tidigt, men det signalerar MCP:s evolution från ett dataprotokoll till ett fullständigt agentapplikationsramverk. Värt att hålla ögonen på.

Styrning: Från Anthropic till Linux Foundation

MCP styrs av Agentic AI Foundation (AAIF) under Linux Foundation, medgrundad av Anthropic, Block och OpenAI. Det spelar roll för företagsadoption: MCP är inte knutet till en enda leverantörs färdplan. 2026-färdplanen fokuserar på transportutveckling, agent-till-agent-kommunikation (en ny "Tasks"-primitiv), styrningens mognad och företagsberedskap.

För team som bygger produktions-AI-system integrerar ramverk som ett autonomt AI-agentramverk som OpenClaw redan med MCP-servrar för att ge agenter verkliga förmågor.

MCP-säkerhet: OAuth 2.1, hot och en praktisk checklista

Säkerhet är där MCP-ekosystemet har mest mark att täcka. Och siffrorna målar en tydlig bild.

88%-problemet: Varför de flesta MCP-servrar är osäkra

Astrix Security analyserade 5 200+ open source MCP-serverimplementationer och fann att 88% kräver autentiseringsuppgifter av något slag -- men 53% förlitar sig på osäkra långlivade statiska hemligheter som API-nycklar och personliga åtkomsttokens hårdkodade i konfigurationsfiler. Bara 8,5% implementerar OAuth.

Det innebär att den överväldigande majoriteten av MCP-servrar i naturen använder autentiseringsmotsvarigheten till att tejpa fast din hemnyckel på ytterdörren.

OAuth 2.1 för MCP-servrar

MCP-specifikationen kräver OAuth 2.1 för alla HTTP-baserade servrar från och med juni 2025-uppdateringen. Flödet fungerar så här: MCP-klienten initierar ett OAuth 2.1-auktoriseringsflöde med servern, erhåller en begränsad åtkomsttoken och inkluderar den i varje efterföljande förfrågan. PKCE (Proof Key for Code Exchange) krävs för alla klienter -- inga undantag.

Om du bygger en MCP-server som körs över Streamable HTTP är OAuth 2.1 inte valfritt. Det är spec-obligatoriskt.

Hotmodell: Vad kan gå fel

Fyra hot förtjänar uppmärksamhet i varje MCP-driftsättning:

• Promptinjektion via verktyg -- En skadlig eller komprometterad datakälla returnerar innehåll utformat för att manipulera modellen. Om ett verktyg hämtar en webbsida och den sidan innehåller dolda instruktioner kan modellen köra dem.
• Förvirrad ombud-attack -- Modellen anropar ett verktyg med bredare behörigheter än användaren avsåg. Om MCP-servern har administratörsåtkomst till en databas kan modellen teoretiskt ta bort en tabell.
• Tokenkoncentrationsrisk -- En MCP-server som håller API-nycklar för GitHub, Slack och din produktionsdatabas är ett enda mål med högt värde. Kompromissa en server, kompromissa allt den ansluter till.
• Osäker transport -- Att köra en HTTP MCP-server utan TLS exponerar varje förfrågan, inklusive OAuth-tokens och känslig data, i klartext.

Säkerhetschecklista för produktions-MCP

1. Implementera OAuth 2.1 för alla servrar exponerade via HTTP. Inga statiska API-nycklar i konfigurationsfiler.
2. Tillämpa minsta-privilegs-omfång. Om ditt verktyg bara läser data ska serverns autentiseringsuppgifter vara skrivskyddade. Ge inte ett rapporteringsverktyg skrivåtkomst.
3. Isolera autentiseringsuppgifter. Varje MCP-server ska ha sina egna omfångsbegränsade tokens. Dela inte en enda "gudtoken" över servrar.
4. Tillämpa TLS överallt. Streamable HTTP utan HTTPS är ett automatiskt nej för produktion.
5. Validera och sanera verktygsutdata. Behandla data som returneras av verktyg på samma sätt som du skulle behandla användarinmatning -- lita inte blint på det.
6. Begränsa hastigheten på verktygsanrop. En okontrollerad agentloop som anropar ett verktyg tusentals gånger kan tömma API-kvoter eller orsaka oavsiktliga bieffekter.
7. Granska och logga varje verktygsanrop. Inkludera förfrågnings-ID:er, tidsstämplar, den anropande modellen och verktygsargumenten. Du behöver detta för felsökning och för säkerhetsincidentrespons.

Felsökning av MCP: Inspector, loggning och vanliga fel

Du kommer att stöta på fel. Varje utvecklare gör det. Så här löser du dem snabbt.

MCP Inspector är det officiella felsökningsverktyget och din första försvarslinje. Det ansluter till valfri MCP-server, upptäcker dess verktyg/resurser/prompter och låter dig anropa dem manuellt medan det visar råa JSON-RPC-trafiken.

# Starta Inspector mot din Python-server
npx @modelcontextprotocol/inspector python weather_server.py

# Eller mot en TypeScript-server
npx @modelcontextprotocol/inspector npx tsx weather-server.ts

Inspector öppnar ett webbläsarbaserat UI med flikar för Verktyg, Resurser, Prompter och ett notispanel. Du kan anropa vilket verktyg som helst med anpassade argument och se exakt vilket JSON som går över nätet. Använd det innan du ansluter till en hostapplikation -- det är mycket enklare att felsöka servern i isolation.

Vanliga fel och lösningar

• "Servern hittades inte" i Claude Desktop -- Nästan alltid ett sökvägsproblem i claude_desktop_config.json. Kontrollera att command leder till en riktig binär och att cwd pekar på rätt katalog. På macOS, använd absoluta sökvägar.
• Verktygsschemavideringsfel -- Om modellen skickar argument som inte matchar verktygets inputSchema avvisar servern anropet. Kontrollera att dina schematyper matchar vad modellen förväntar sig. Zod (TypeScript) och typannoteringar (Python) fångar de flesta av dessa vid definitionstid.
• Transportanslutningsavbrott -- För stdio innebär det vanligtvis att serverprocessen kraschade. Kontrollera stderr-utdata. För Streamable HTTP, kontrollera timeout-inställningar -- långkörande verktyg kan överskrida standard HTTP-timeout:ar.
• "Permission denied" eller 401-fel -- OAuth-omfång för smalt. Servern avvisar token eftersom den inte har de nödvändiga behörigheterna. Bredda omfånget, men bara så mycket som verktyget faktiskt behöver.

Bästa praxis för loggning

Strukturera dina loggar med förfrågnings-ID:er så att du kan spåra en enda användarförfrågan genom MCP-klienten, servern och eventuella nedströms-API:er. Logga varje tools/call-anrop med verktygsnamnet, argumenten, svarstiden och resultatstatusen. I produktion, skicka dessa loggar till en observabilitetsplattform -- när något går fel klockan 3 på natten kommer du att vara glad att du gjorde det. Läs mer om guide till LLM function calling.

Hur Techsy bygger med MCP

Vi har integrerat MCP i kundprojekt sedan tidigt 2025, och det mönster vi ser oftast är detta: ett team har en AI-funktion som fungerar med en modell och en handfull verktyg, men de planerar att skala -- fler modeller, fler datakällor, fler agentförmågor. Det är vändpunkten där MCP börjar löna sig.

Vår approach följer tre steg:

1. Bedöm lämpligheten. Inte varje projekt behöver MCP. Om du anropar två verktyg från en enda modell är function calling enklare och det berättar vi. MCP är vettigt när du ansluter 3 eller fler datakällor, stöder flera modeller, eller bygger agentarbetsflöden där verktyg behöver vara upptäckbara.
2. Bygg och testa servrar i isolation. Vi utvecklar anpassade MCP-servrar för varje datakälla -- interna databaser, SaaS-API:er, proprietära tjänster -- och validerar dem med MCP Inspector innan vi ansluter till en host.
3. Driftsätt med Streamable HTTP och OAuth 2.1. För produktion kör vi MCP-servrar som containeriserade tjänster bakom TLS, med begränsade OAuth-tokens och strukturerad loggning från dag ett. Inga statiska hemligheter.

De vanligaste integrationerna vi bygger: ansluta AI-assistenter till interna Postgres-databaser, bygga anpassade MCP-servrar för kunders SaaS-plattformar och migrera team från spridda function calling-upplägg till en standardiserad MCP-arkitektur.

Bygger du AI-drivna verktyg som behöver ansluta till din infrastruktur? Vi hjälper team att designa och implementera MCP-integrationer. Få en gratis konsultation

Vanliga frågor om MCP

Vad är Model Context Protocol (MCP)?

MCP är en öppen standard, ursprungligen skapad av Anthropic och nu styrd av Linux Foundation, som definierar hur AI-modeller ansluter till externa verktyg, datakällor och tjänster. Det standardiserar integrationsskiktet så att en MCP-server fungerar med valfri kompatibel modell -- som ett universellt uttag för AI.

Hur fungerar MCP?

MCP använder en tredelararkitektur: en host-applikation (som Claude Desktop eller Cursor), en MCP-klient inuti hosten som hanterar anslutningar, och MCP-servrar som exponerar verktyg och data. All kommunikation använder JSON-RPC 2.0-meddelanden över antingen stdio (lokalt) eller Streamable HTTP (fjärr).

Vad används MCP till?

Vanliga användningsfall inkluderar att ansluta AI-assistenter till databaser (Postgres, MySQL), integrera med kodplattformar (GitHub, GitLab), komma åt SaaS-verktyg (Slack, Notion, Google Drive) och bygga autonoma AI-agenter som behöver interagera med verkliga tjänster.

Är MCP detsamma som function calling?

Nej. Function calling är modellspecifikt (OpenAIs format skiljer sig från Anthropics) och per förfrågan -- du skickar verktygscheman med varje API-anrop. MCP är ett standardiserat protokoll som fungerar över modeller, stöder verktygsupptäckt och inkluderar resurser och prompter utöver bara funktionskörning.

Vad är MCP-servrar?

MCP-servrar är program som exponerar verktyg, resurser och prompter till AI-modeller via MCP-protokollet. De omsluter externa API:er och datakällor i ett standardiserat gränssnitt. Exempel inkluderar GitHub MCP-servern (för PR- och issue-hantering) och Postgres MCP-servern (för databasfrågor).

Hur bygger jag en MCP-server?

Använd Python med FastMCP (pip install fastmcp) eller TypeScript med officiell SDK (npm install @modelcontextprotocol/sdk). Definiera dina verktyg som dekorerade funktioner (Python) eller registrerade handlers (TypeScript), kör sedan servern. Se handledningsavsnittet ovan för fullständig fungerande kod.

Är MCP säkert?

Protokollet i sig stöder OAuth 2.1 för autentisering och begränsade behörigheter. Men Astrix Security-forskning fann att 88% av befintliga MCP-serverimplementationer förlitar sig på statiska hemligheter snarare än OAuth. Protokollet är säkert by design, men de flesta verkliga driftsättningar har inte hunnit ikapp ännu.

Vilka LLM:er stöder MCP?

Claude har inbyggt MCP-stöd sedan det skapades i november 2024. ChatGPT lade till stöd i mars 2025 och Gemini följde i april 2025. Open source-modeller kan använda MCP via adaptrar i LangChain och LlamaIndex.

Vad är skillnaden mellan MCP och en REST API?

REST API:er är utformade för allmän tjänst-till-tjänst-kommunikation. MCP är utformat specifikt för AI-modellinteraktion -- det inkluderar verktygsupptäckt, schemaförhandling, resursåtkomst och promptmallar som REST inte har. Du skulle inte ersätta dina REST API:er med MCP; de tjänar olika lager.

Vem underhåller MCP nu?

Linux Foundations Agentic AI Foundation (AAIF), bildad i december 2025, styr MCP. Det medgrundades av Anthropic, Block och OpenAI. Den här leverantörsneutrala styrningen är en viktig anledning till att företag antar MCP.

Vad är Streamable HTTP i MCP?

Streamable HTTP är produktionstransportmekanismen tillagd i 2025 MCP-specuppdateringen. Den ersätter den äldre HTTP+SSE-transporten med en renare design: klienter skickar HTTP POST-förfrågningar och servrar kan svara synkront eller via SSE-streaming. Det fungerar bakom lastbalanserare och stöder standard HTTP-autentisering.

Hur många MCP-servrar finns det?

Linux Foundation citerade 10 000+ aktiva servrar och 97 miljoner månatliga SDK-nedladdningar när MCP donerades till AAIF i december 2025. Ekosystemet spänner över databaser, kodverktyg, SaaS-integrationer, sökmotorer och molninfrastrukturleverantörer.

Slutsats

MCP har gått från Anthropics open source-experiment till branschens standardprotokoll för att ansluta AI-modeller till verktyg på lite mer än ett år. Här är vad som spelar roll:

• MCP löser M x N-problemet -- en server fungerar med varje kompatibel modell, en klient fungerar med varje server
• Du kan bygga en fungerande MCP-server på under 50 rader Python (FastMCP) eller TypeScript
• Använd stdio för utveckling, Streamable HTTP för produktion -- transportvalet är enkelt
• Säkra dina servrar med OAuth 2.1 -- 88% av nuvarande implementationer gör det inte, och det är en verklig risk
• Ekosystemet är produktionsklar -- 10 000+ servrar, alla stora LLM:er, leverantörsneutral styrning under Linux Foundation

Framåt fokuserar 2026-färdplanen på agent-till-agent-kommunikation via en ny Tasks-primitiv, förbättrad företagssäkerhet och MCP Apps för interaktivt serverdriven UI. MCP är inte längre bara ett protokoll för verktygsåtkomst -- det håller på att bli infrastrukturlagret för agentisk AI.

Börja med handledningskoden ovan, testa den i MCP Inspector och anslut den till Claude Desktop. Du kommer ha en fungerande MCP-integration på under en timme.

Källor

• MCP-specifikation (2025-11-25)
• MCP-auktoriseringsspecifikation
• MCP-transportspecifikation
• MCP Inspector-dokumentation
• Introduktion av Model Context Protocol -- Anthropic
• Donation av MCP till Linux Foundation -- Anthropic
• Linux Foundation AAIF-tillkännagivande
• Google Cloud MCP-stöd
• FastMCP Python SDK
• MCP TypeScript SDK
• Astrix Security: Tillståndet för MCP-serversäkerhet 2025
• MCP 2026-färdplan