Model Context Protocol: Deinen ersten MCP-Server heute bauen

Das Model Context Protocol (MCP) ist ein offener Standard, der KI-Modellen eine universelle Möglichkeit gibt, sich mit externen Tools, Datenquellen und Diensten zu verbinden. Statt für jede Modell-Tool-Kombination eigenen Integrationscode zu schreiben, schreibst du einmal einen MCP-Server und jedes kompatible Modell kann ihn nutzen. Anthropic hat MCP Ende 2024 entwickelt, die Linux Foundation verwaltet es heute, und OpenAI, Google sowie der Rest des agentischen KI-Ökosystems haben es übernommen. Hier ist alles, was du über MCP verstehen, aufbauen und deployen musst.

MCP auf einen Blick

Wenn du die Kurzversion möchtest, bevor du in 6.000 Wörter Details eintauchst, hier ist sie.

Jetzt entpacken wir jeden dieser Punkte, beginnend damit, was MCP eigentlich ist und welches Problem es notwendig gemacht hat.

Was ist das Model Context Protocol?

Das Model Context Protocol ist ein offenes, JSON-RPC-basiertes Protokoll, das standardisiert, wie KI-Modelle externe Tools und Daten entdecken und mit ihnen interagieren. Stell es dir wie HTTP für KI-Integrationen vor -- eine gemeinsame Sprache, die jedes Modell und jedes Tool sprechen kann.

Du hast wahrscheinlich die USB-C-Analogie gehört, und sie ist bis zu einem gewissen Punkt nützlich: Vor USB-C benötigte jedes Gerät sein eigenes Kabel. MCP macht dasselbe für KI, aber die Analogie unterschätzt es. USB-C überträgt nur Daten und Strom. MCP überträgt Tool-Definitionen, Datenzugriffsmuster, wiederverwendbare Prompt-Vorlagen und lässt sogar Server Vervollständigungen vom Modell anfordern. Es ist ein reichhaltigeres Protokoll als eine Kabelmetapher nahelegt.

Das M x N Problem, das MCP löst

Ohne MCP erfordert die Verbindung von M Modellen mit N Tools M x N benutzerdefinierte Integrationen. Angenommen, du unterstützt 5 LLMs (Claude, GPT-4, Gemini, Llama, Mistral) und musst sie auf 10 Tools zugreifen lassen (GitHub, Postgres, Slack, Jira und so weiter). Das sind 50 maßgeschneiderte Integrationsschichten, jede mit eigener Authentifizierung, Fehlerbehandlung und Datenformatierung.

Mit MCP implementiert jedes Modell das MCP-Client-Protokoll einmal, und jedes Tool implementiert einmal einen MCP-Server. Jetzt sind es 5 + 10 = 15 Implementierungen statt 50. Ein neues Modell hinzufügen? Es funktioniert sofort mit allen 10 Tools. Ein neues Tool hinzufügen? Alle 5 Modelle können es nutzen.

Eine kurze Geschichte von MCP

Anthropic hat MCP im November 2024 als Open Source veröffentlicht zusammen mit SDKs für Python und TypeScript sowie Konnektoren für Claude Desktop. Die Übernahme ging schnell. OpenAI hat MCP-Unterstützung für ChatGPT im März 2025 hinzugefügt. Google folgte für Gemini im April 2025. Im Dezember 2025 spendete Anthropic MCP an die neue Agentic AI Foundation (AAIF) der Linux Foundation, mitgegründet mit Block und OpenAI, was MCP zu einem herstellerneutralen Standard mit branchenübergreifender Verwaltung macht.

Was MCP NICHT ist:

• Kein Modell und kein KI-Framework (es ist ein Protokoll, wie HTTP)
• Kein Ersatz für LangChain oder LlamaIndex (das sind Orchestrierungsschichten; MCP sitzt darunter)
• Nicht auf Anthropic oder Claude beschränkt (es ist modellunabhängig by design)
• Nicht dasselbe wie Function Calling (mehr dazu im Vergleichsabschnitt)

Wie funktioniert MCP? Architektur im Detail

MCP hat drei Rollen, und sie zu verwechseln ist der häufigste Anfängerfehler. Lass uns die Unterschiede klarstellen.

Host, Client und Server -- Was ist der Unterschied?

Hier ist ein konkretes Beispiel: Du bittest Claude Desktop, deine offenen GitHub-Pull-Requests zu prüfen. Claude Desktop ist der Host. Sein eingebauter MCP-Client öffnet eine Verbindung zum GitHub MCP-Server. Der Server ruft die GitHub-API auf, holt deine PRs und gibt die Ergebnisse an den Client zurück, der sie an das Modell weitergibt.

Ein einzelner Host kann mehrere Clients betreiben, die jeweils mit einem anderen Server verbunden sind. So kann Claude Desktop gleichzeitig auf GitHub, deine Postgres-Datenbank und Slack zugreifen -- drei separate MCP-Server, drei separate Client-Verbindungen, ein Host.

Wie Nachrichten fließen (JSON-RPC 2.0)

Die gesamte MCP-Kommunikation verwendet JSON-RPC 2.0 -- ein leichtgewichtiges Request/Response-Protokoll. So sieht ein tools/list-Austausch auf dem Draht aus:

// Client-Anfrage: "Welche Tools hast du?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Server-Antwort: ein Tool verfügbar
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Aktuelles Wetter für eine Stadt abrufen",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Das Modell liest diese Tool-Definitionen, entscheidet basierend auf der Anfrage des Benutzers, wann sie aufzurufen sind, und der Client sendet eine tools/call-Anfrage zurück an den Server mit den entsprechenden Argumenten.

Verbindungslebenszyklus

Jede MCP-Sitzung folgt demselben Lebenszyklus:

1. Initialisierung -- Client sendet Capabilities, Server antwortet mit seinen eigenen
2. Capability-Aushandlung -- beide Seiten einigen sich auf unterstützte Funktionen (Tools, Resources, Prompts, Sampling)
3. Bereit -- die Verbindung ist aktiv; Anfragen fließen in beide Richtungen
4. Anfragen/Antworten -- tools/call, resources/read usw.
5. Herunterfahren -- saubere Trennung

Dieser Handshake sorgt für Vorwärtskompatibilität. Wenn ein Server ein neues Primitive hinzufügt, ignorieren ältere Clients es elegant, anstatt abzustürzen.

MCP-Primitive: Tools, Resources, Prompts und Sampling

MCP definiert vier Primitive, und zu verstehen, wer jedes kontrolliert, ist der Schlüssel für das Design guter MCP-Server.

Tools (Modellgesteuert)

Tools sind Funktionen, die das Modell aufrufen kann. Der Server deklariert sie mit einem Namen, einer Beschreibung und einer JSON-Schema-Eingabedefinition. Das Modell liest diese Definitionen und entscheidet, wenn eine Benutzeranfrage es erfordert, das Tool aufzurufen.

// Client sendet tools/call-Anfrage
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Berlin" }
  }
}

Wenn du OpenAI Function Calling verwendet hast, werden sich Tools vertraut anfühlen -- aber sie sind für jedes MCP-kompatible Modell standardisiert.

Resources (Anwendungsgesteuert)

Resources sind schreibgeschützte Datenendpunkte. Im Gegensatz zu Tools entscheidet das Modell nicht selbst, eine Resource abzurufen -- die Host-Anwendung oder der Benutzer hängt Resources explizit an den Konversationskontext an. Stell sie dir wie GET-Endpunkte vor: postgres://mydb/users/schema, file://docs/api-reference.md.

Resources unterstützen Abonnements über resources/subscribe, sodass der Client benachrichtigt werden kann, wenn sich Daten ändern.

Prompts (Benutzergesteuert)

Prompts sind wiederverwendbare Vorlagen, die ein MCP-Server bereitstellt. Ein code_review-Prompt könnte einen Dateipfad akzeptieren und eine strukturierte Review-Anfrage generieren. Der Benutzer (oder die Host-UI) löst Prompts explizit aus -- sie werden nicht automatisch vom Modell aufgerufen.

Sampling (Server-initiiert) -- Fortgeschritten

Hier ist das Primitive, das die meisten Leitfäden überspringen. Sampling ermöglicht es dem Server, den Client zu bitten, eine Vervollständigung mit dem LLM zu generieren. Dies kehrt den üblichen Fluss um: Statt dass das Modell ein Tool aufruft, ruft das Tool das Modell auf.

Warum? Agentische Schleifen. Stell dir einen MCP-Server vor, der Support-Tickets bearbeitet. Er liest das Ticket (eine Resource), verwendet sampling/createMessage, um das Modell nach einer Zusammenfassung zu fragen, und nutzt dann diese Zusammenfassung, um das Ticket über ein Tool weiterzuleiten. Der Server orchestriert einen mehrstufigen Workflow unter Nutzung der Intelligenz des Modells.

Sampling wird von der Host-Anwendung kontrolliert -- der Benutzer muss es genehmigen, und der Host kontrolliert, was der Server anfordern kann. Das verhindert unkontrollierte Schleifen und bewahrt die menschliche Aufsicht.

Deinen ersten MCP-Server bauen: Python und TypeScript im Vergleich

Genug Theorie. Lass uns einen funktionierenden MCP-Server bauen, der ein get_weather-Tool bereitstellt. Ich zeige sowohl Python als auch TypeScript, damit du die Entwicklererfahrung vergleichen und den Stack wählen kannst, der zu deinem Projekt passt.

Python mit FastMCP

FastMCP ist das offizielle High-Level-Python-SDK. Es übernimmt die gesamte Protokoll-Infrastruktur, sodass du dich auf deine Tool-Logik konzentrieren kannst.

# FastMCP installieren
pip install fastmcp

# weather_server.py
from fastmcp import FastMCP

mcp = FastMCP("Weather Server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Aktuelles Wetter für eine Stadt abrufen."""
    # In der Produktion hier eine echte Wetter-API aufrufen
    weather_data = {
        "Berlin": "Bewölkt, 12°C",
        "Tokyo": "Sonnig, 22°C",
        "New York": "Regnerisch, 8°C",
    }
    return weather_data.get(city, f"Keine Daten für {city}")

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

Das war's -- 15 Zeilen. FastMCP leitet das Eingabe-Schema des Tools aus den Python-Typhinweisen und dem Docstring ab. Kein JSON-Schema-Boilerplate.

TypeScript mit dem offiziellen SDK

Das TypeScript-SDK (@modelcontextprotocol/sdk) ist etwas expliziter, gibt dir aber vollständige Kontrolle über Schema-Definitionen.

# SDK und Zod für die Schema-Validierung installieren
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: "Weather Server",
  version: "1.0.0",
});

server.tool(
  "get_weather",
  "Aktuelles Wetter für eine Stadt abrufen",
  { city: z.string() },
  async ({ city }) => {
    const weatherData: Record<string, string> = {
      Berlin: "Bewölkt, 12°C",
      Tokyo: "Sonnig, 22°C",
      "New York": "Regnerisch, 8°C",
    };
    return {
      content: [
        { type: "text", text: weatherData[city] ?? `Keine Daten für ${city}` },
      ],
    };
  }
);

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

Die TypeScript-Version verwendet Zod-Schemas statt Typhinweise und gibt strukturierte Inhaltsblöcke zurück. Ausführlicher, aber die Typsicherheit ist ausgezeichnet.

Mit Claude Desktop verbinden

Um einen der Server in Claude Desktop zu integrieren, füge ihn zu deiner claude_desktop_config.json hinzu:

{
  "mcpServers": {
    "weather-python": {
      "command": "python",
      "args": ["weather_server.py"],
      "cwd": "/pfad/zu/deinem/projekt"
    },
    "weather-typescript": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "cwd": "/pfad/zu/deinem/projekt"
    }
  }
}

Starte Claude Desktop neu, und beide Wetter-Server erscheinen in der Tool-Liste. Frag "Wie ist das Wetter in Berlin?" und das Modell ruft dein get_weather-Tool automatisch auf.

Mit MCP Inspector testen

Bevor du deinen Server mit einem Host verbindest, teste ihn isoliert mit dem MCP Inspector:

npx @modelcontextprotocol/inspector python weather_server.py

Der Inspector öffnet eine Browser-UI, in der du entdeckte Tools siehst, sie manuell aufrufst und die JSON-RPC-Nachrichten inspizierst, die hin und her gehen. Es ist das beste Debugging-Tool im MCP-Ökosystem -- nutze es früh und oft.

MCP-Transporte: stdio für Entwicklung, Streamable HTTP für Produktion

MCP-Nachrichten brauchen einen Weg, zwischen Client und Server zu reisen. Das ist die Transportschicht, und die richtige Wahl ist wichtig.

stdio funktioniert, indem der MCP-Server als Unterprozess gestartet und über stdin/stdout kommuniziert wird. Das ist das, was du im obigen Tutorial verwendet hast -- keine Ports, kein TLS, keine Authentifizierung nötig. Perfekt für die Entwicklung und einzelne lokale Tools.

Streamable HTTP ist der Produktionstransport, der im 2025-Spezifikationsupdate hinzugefügt wurde. Clients senden Standard-HTTP-POST-Anfragen an den Server. Der Server kann synchron oder über einen SSE-Stream für längere Operationen antworten. Er ist stateless-freundlich, funktioniert hinter Load Balancern und unterstützt Standard-HTTP-Authentifizierung.

Wenn du ältere Tutorials siehst, die "HTTP+SSE" als zwei separate Transporte erwähnen (einer zum Senden, einer zum Empfangen), ist das der veraltete Ansatz. Streamable HTTP konsolidiert beides in einem einzigen, saubereren Mechanismus.

Die Entscheidung ist einfach: Nutze stdio bei lokaler Entwicklung, wechsle zu streamable-http beim Deployment für andere.

// Wechsel von stdio zu Streamable HTTP in 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 APIs -- Wann was verwenden

Das ist die Frage, die in jeder MCP-Diskussion auftaucht, also lass uns sie mit einem direkten Vergleich klären.

Wann Function Calling ausreicht

Wenn du weniger als 5 Tools hast und ein Modell verwendest, ist Function Calling einfacher. Du definierst deine Tool-Schemas inline bei jedem API-Aufruf, das Modell gibt den Funktionsnamen und die Argumente zurück, und du führst sie in deinem Anwendungscode aus. Kein Server zu betreiben, kein Protokoll zu lernen. Für einen Chatbot, der den Bestellstatus prüft und FAQs nachschlägt, ist Function Calling völlig in Ordnung.

Wann MCP den Aufwand wert ist

MCP rechtfertigt seine Komplexität, wenn:

• Du mehrere LLMs unterstützt und Tool-Definitionen nicht für jeden Anbieter neu schreiben möchtest
• Du Tool-Erkennung brauchst -- das Modell kann abfragen, was verfügbar ist, statt dass du Schemas hardcodest
• Du Resources und Prompts möchtest, nicht nur Tool-Aufrufe
• Du KI-Agenten baust, die autonom koordinieren und eine standardisierte Integrationsschicht benötigen
• Dein Team wächst und verschiedene Ingenieure verschiedene Tools bauen -- MCP lässt sie unabhängig arbeiten

Fazit: MCP gewinnt, wenn du standardisierten, Mehrmodell-Tool-Zugriff brauchst. Function Calling gewinnt für einfache Einzelmodell-Anwendungsfälle. REST APIs bleiben die richtige Wahl für traditionelle Service-to-Service-Kommunikation ohne LLM.

Das MCP-Ökosystem 2026: Wer unterstützt es und was ist verfügbar

MCP ist in weniger als 18 Monaten von einem Anthropic-Nebenprojekt zu einem Industriestandard geworden. Hier ist der aktuelle Stand.

Welche LLMs unterstützen MCP?

Beliebte MCP-Server, die es sich zu kennen lohnt

Die Ankündigung der AAIF der Linux Foundation nannte 10.000+ aktive Server und 97 Millionen monatliche SDK-Downloads zum Zeitpunkt der Übergabe von MCP im Dezember 2025. Das Ökosystem ist nicht mehr experimentell -- es ist produktionstauglich.

MCP Apps ist ein neues Primitive, das im Januar 2026 eingeführt wurde. Es ermöglicht Servern, interaktive UI-Komponenten bereitzustellen, die innerhalb der Host-Anwendung gerendert werden. Noch in der Frühphase, aber es signalisiert MCPs Entwicklung von einem Datenprotokoll zu einem vollständigen Agentenanwendungs-Framework. Lohnt sich, es im Auge zu behalten.

Governance: Von Anthropic zur Linux Foundation

MCP wird von der Agentic AI Foundation (AAIF) unter der Linux Foundation verwaltet, mitgegründet von Anthropic, Block und OpenAI. Das ist wichtig für die Unternehmensübernahme: MCP ist nicht an die Roadmap eines einzelnen Anbieters gebunden. Die 2026-Roadmap konzentriert sich auf Transport-Entwicklung, Agent-zu-Agent-Kommunikation (ein neues "Tasks"-Primitive), Governance-Reifung und Unternehmenstauglichkeit.

Für Teams, die produktive KI-Systeme bauen, integrieren Frameworks wie ein autonomes KI-Agenten-Framework wie OpenClaw bereits mit MCP-Servern, um Agenten reale Fähigkeiten zu geben.

MCP-Sicherheit: OAuth 2.1, Bedrohungen und eine praktische Checkliste

Sicherheit ist der Bereich, in dem das MCP-Ökosystem am meisten aufzuholen hat. Und die Zahlen zeichnen ein deutliches Bild.

Das 88%-Problem: Warum die meisten MCP-Server unsicher sind

Astrix Security analysierte 5.200+ Open-Source-MCP-Server-Implementierungen und stellte fest, dass 88% irgendwie Anmeldedaten benötigen -- aber 53% auf unsichere, langlebige statische Geheimnisse wie API-Schlüssel und persönliche Zugangstokens setzen, die in Konfigurationsdateien hardcodiert sind. Nur 8,5% implementieren OAuth.

Das bedeutet, dass die überwiegende Mehrheit der MCP-Server in freier Wildbahn das Authentifizierungsäquivalent verwendet, deinen Hausschlüssel an die Haustür zu kleben.

OAuth 2.1 für MCP-Server

Die MCP-Spezifikation erfordert OAuth 2.1 für alle HTTP-basierten Server ab dem Juni-2025-Update. Der Ablauf funktioniert so: Der MCP-Client initiiert einen OAuth 2.1-Autorisierungsfluss mit dem Server, erhält ein Zugriffstoken mit begrenztem Geltungsbereich und fügt es bei jeder nachfolgenden Anfrage ein. PKCE (Proof Key for Code Exchange) ist für alle Clients erforderlich -- keine Ausnahmen.

Wenn du einen MCP-Server baust, der über Streamable HTTP läuft, ist OAuth 2.1 nicht optional. Es ist in der Spezifikation vorgeschrieben.

Bedrohungsmodell: Was schiefgehen kann

Vier Bedrohungen verdienen Aufmerksamkeit bei jeder MCP-Bereitstellung:

• Prompt-Injection über Tools -- Eine bösartige oder kompromittierte Datenquelle gibt Inhalte zurück, die darauf ausgelegt sind, das Modell zu manipulieren. Wenn ein Tool eine Webseite abruft und diese Seite versteckte Anweisungen enthält, könnte das Modell sie ausführen.
• Confused-Deputy-Angriff -- Das Modell ruft ein Tool mit umfangreicheren Berechtigungen auf, als der Benutzer beabsichtigt hat. Wenn der MCP-Server Administratorzugriff auf eine Datenbank hat, könnte das Modell theoretisch eine Tabelle löschen.
• Token-Konzentrierungsrisiko -- Ein MCP-Server, der API-Schlüssel für GitHub, Slack und deine Produktionsdatenbank hält, ist ein einzelnes hochwertiges Ziel. Einen Server kompromittieren, alles kompromittieren, mit dem er verbunden ist.
• Unsicherer Transport -- Einen HTTP-MCP-Server ohne TLS zu betreiben, legt jede Anfrage offen, einschließlich OAuth-Tokens und sensibler Daten, im Klartext.

Sicherheitscheckliste für Produktions-MCP

1. OAuth 2.1 implementieren für jeden Server, der über HTTP zugänglich ist. Keine statischen API-Schlüssel in Konfigurationsdateien.
2. Least-Privilege-Scoping anwenden. Wenn dein Tool nur Daten liest, sollten die Anmeldedaten des Servers schreibgeschützt sein. Gib einem Reporting-Tool keinen Schreibzugriff.
3. Anmeldedaten isolieren. Jeder MCP-Server sollte seine eigenen begrenzten Tokens haben. Teile kein einzelnes "Gott-Token" über Server hinweg.
4. TLS überall erzwingen. Streamable HTTP ohne HTTPS ist für die Produktion ein automatisches No-Go.
5. Tool-Ausgaben validieren und bereinigen. Behandle Daten, die von Tools zurückgegeben werden, genauso wie Benutzereingaben -- vertraue ihnen nicht blind.
6. Tool-Aufrufe ratelimiten. Eine außer Kontrolle geratene Agentenloop, die ein Tool tausende Male aufruft, kann API-Quoten erschöpfen oder unbeabsichtigte Nebeneffekte verursachen.
7. Jeden Tool-Aufruf prüfen und protokollieren. Füge Request-IDs, Zeitstempel, das aufrufende Modell und die Tool-Argumente ein. Du brauchst das für Debugging und für die Reaktion auf Sicherheitsvorfälle.

MCP debuggen: Inspector, Logging und häufige Fehler

Du wirst auf Fehler stoßen. Jeder Entwickler tut es. Hier ist, wie du sie schnell behebst.

MCP Inspector ist das offizielle Debugging-Tool und deine erste Verteidigungslinie. Es verbindet sich mit jedem MCP-Server, entdeckt seine Tools/Resources/Prompts und lässt dich sie manuell aufrufen, während es den rohen JSON-RPC-Traffic zeigt.

# Inspector gegen deinen Python-Server starten
npx @modelcontextprotocol/inspector python weather_server.py

# Oder gegen einen TypeScript-Server
npx @modelcontextprotocol/inspector npx tsx weather-server.ts

Der Inspector öffnet eine browserbasierte UI mit Tabs für Tools, Resources, Prompts und einem Benachrichtigungsbereich. Du kannst jedes Tool mit benutzerdefinierten Argumenten aufrufen und genau sehen, welches JSON über den Draht geht. Verwende ihn, bevor du dich mit einer Host-Anwendung verbindest -- es ist viel einfacher, den Server isoliert zu debuggen.

Häufige Fehler und Lösungen

• "Server nicht gefunden" in Claude Desktop -- Fast immer ein Pfadproblem in claude_desktop_config.json. Überprüfe, ob command zu einem echten Binary auflöst und cwd auf das richtige Verzeichnis zeigt. Unter macOS verwende absolute Pfade.
• Tool-Schema-Validierungsfehler -- Wenn das Modell Argumente sendet, die nicht dem inputSchema des Tools entsprechen, lehnt der Server den Aufruf ab. Prüfe, dass deine Schema-Typen mit dem übereinstimmen, was das Modell erwartet. Zod (TypeScript) und Typhinweise (Python) fangen die meisten davon zur Definitionszeit ab.
• Transport-Verbindungsabbrüche -- Für stdio bedeutet das normalerweise, dass der Server-Prozess abgestürzt ist. Prüfe die stderr-Ausgabe. Für Streamable HTTP überprüfe die Timeout-Einstellungen -- langwierige Tools können Standard-HTTP-Timeouts überschreiten.
• "Permission denied" oder 401-Fehler -- OAuth-Scope zu eng. Der Server lehnt das Token ab, weil es nicht die erforderlichen Berechtigungen hat. Erweitere den Scope, aber nur so weit wie das Tool tatsächlich benötigt.

Logging Best Practices

Strukturiere deine Logs mit Request-IDs, damit du eine einzelne Benutzeranfrage über den MCP-Client, Server und nachgelagerte APIs hinweg verfolgen kannst. Protokolliere jeden tools/call-Aufruf mit dem Tool-Namen, Argumenten, Antwortzeit und Ergebnisstatus. In der Produktion leite diese Logs an eine Observability-Plattform weiter -- wenn um 3 Uhr morgens etwas schief geht, wirst du froh sein, dass du es getan hast.

Wie Techsy mit MCP baut

Wir integrieren MCP seit Anfang 2025 in Kundenprojekte, und das Muster, das wir am häufigsten sehen, ist folgendes: Ein Team hat eine KI-Funktion, die mit einem Modell und einer Handvoll Tools funktioniert, plant aber zu skalieren -- mehr Modelle, mehr Datenquellen, mehr Agentenfähigkeiten. Das ist der Wendepunkt, an dem sich MCP zu lohnen beginnt.

Unser Ansatz folgt drei Schritten:

1. Eignung bewerten. Nicht jedes Projekt braucht MCP. Wenn du zwei Tools von einem einzelnen Modell aufrufst, ist Function Calling einfacher, und wir werden dir das sagen. MCP macht Sinn, wenn du 3+ Datenquellen verbindest, mehrere Modelle unterstützt oder Agenten-Workflows baust, bei denen Tools erkennbar sein müssen.
2. Server isoliert bauen und testen. Wir entwickeln benutzerdefinierte MCP-Server für jede Datenquelle -- interne Datenbanken, SaaS-APIs, proprietäre Dienste -- und validieren sie mit dem MCP Inspector, bevor wir uns mit einem Host verbinden.
3. Mit Streamable HTTP und OAuth 2.1 deployen. Für die Produktion betreiben wir MCP-Server als containerisierte Dienste hinter TLS, mit begrenzten OAuth-Tokens und strukturiertem Logging von Anfang an. Keine statischen Geheimnisse.

Die häufigsten Integrationen, die wir bauen: KI-Assistenten mit internen Postgres-Datenbanken verbinden, benutzerdefinierte MCP-Server für Kunden-SaaS-Plattformen bauen und Teams von verstreuten Function-Calling-Setups zu einer standardisierten MCP-Architektur migrieren.

Baust du KI-gestützte Tools, die sich mit deiner Infrastruktur verbinden müssen? Wir helfen Teams dabei, MCP-Integrationen zu entwerfen und zu implementieren. Kostenlose Beratung anfragen

Häufig gestellte Fragen zu MCP

Was ist das Model Context Protocol (MCP)?

MCP ist ein offener Standard, ursprünglich von Anthropic erstellt und jetzt von der Linux Foundation verwaltet, der definiert, wie KI-Modelle sich mit externen Tools, Datenquellen und Diensten verbinden. Er standardisiert die Integrationsschicht, sodass ein MCP-Server mit jedem kompatiblen Modell funktioniert -- wie ein Universalstecker für KI.

Wie funktioniert MCP?

MCP verwendet eine dreiteilige Architektur: eine Host-Anwendung (wie Claude Desktop oder Cursor), einen MCP-Client innerhalb des Hosts, der Verbindungen verwaltet, und MCP-Server, die Tools und Daten bereitstellen. Die gesamte Kommunikation verwendet JSON-RPC 2.0-Nachrichten über entweder stdio (lokal) oder Streamable HTTP (remote).

Wofür wird MCP verwendet?

Häufige Anwendungsfälle umfassen die Verbindung von KI-Assistenten mit Datenbanken (Postgres, MySQL), die Integration mit Code-Plattformen (GitHub, GitLab), den Zugriff auf SaaS-Tools (Slack, Notion, Google Drive) und den Aufbau autonomer KI-Agenten, die mit realen Diensten interagieren müssen.

Ist MCP dasselbe wie Function Calling?

Nein. Function Calling ist modellspezifisch (OpenAIs Format unterscheidet sich von Anthropics) und pro Anfrage -- du sendest Tool-Schemas bei jedem API-Aufruf. MCP ist ein standardisiertes Protokoll, das über Modelle hinweg funktioniert, Tool-Erkennung unterstützt und Resources und Prompts über die reine Funktionsausführung hinaus einschließt.

Was sind MCP-Server?

MCP-Server sind Programme, die Tools, Resources und Prompts über das MCP-Protokoll für KI-Modelle bereitstellen. Sie verpacken externe APIs und Datenquellen in einer standardisierten Schnittstelle. Beispiele sind der GitHub-MCP-Server (für PR- und Issue-Verwaltung) und der Postgres-MCP-Server (für Datenbankabfragen).

Wie baue ich einen MCP-Server?

Verwende Python mit FastMCP (pip install fastmcp) oder TypeScript mit dem offiziellen SDK (npm install @modelcontextprotocol/sdk). Definiere deine Tools als dekorierte Funktionen (Python) oder registrierte Handler (TypeScript), dann starte den Server. Sieh dir den Tutorial-Abschnitt oben für vollständigen Arbeitscode an.

Ist MCP sicher?

Das Protokoll selbst unterstützt OAuth 2.1 zur Authentifizierung und begrenzte Berechtigungen. Jedoch fand die Astrix-Security-Forschung, dass 88% der bestehenden MCP-Server-Implementierungen auf statische Geheimnisse statt OAuth setzen. Das Protokoll ist sicher by design, aber die meisten realen Deployments haben noch nicht aufgeholt.

Welche LLMs unterstützen MCP?

Claude hat native MCP-Unterstützung seit seiner Erstellung im November 2024. ChatGPT hat Unterstützung im März 2025 hinzugefügt, und Gemini folgte im April 2025. Open-Source-Modelle können MCP über Adapter in LangChain und LlamaIndex verwenden.

Was ist der Unterschied zwischen MCP und einer REST API?

REST APIs sind für allgemeine Service-to-Service-Kommunikation konzipiert. MCP ist speziell für die Interaktion mit KI-Modellen konzipiert -- es umfasst Tool-Erkennung, Schema-Aushandlung, Ressourcenzugriff und Prompt-Vorlagen, die REST nicht hat. Du würdest deine REST-APIs nicht durch MCP ersetzen; sie dienen verschiedenen Schichten.

Wer pflegt MCP jetzt?

Die Agentic AI Foundation (AAIF) der Linux Foundation, gegründet im Dezember 2025, verwaltet MCP. Sie wurde von Anthropic, Block und OpenAI mitgegründet. Diese herstellerneutrale Governance ist ein Hauptgrund, warum Unternehmen MCP übernehmen.

Was ist Streamable HTTP in MCP?

Streamable HTTP ist der Produktionstransportmechanismus, der im 2025-MCP-Spezifikationsupdate hinzugefügt wurde. Er ersetzt den älteren HTTP+SSE-Transport durch ein saubereres Design: Clients senden HTTP-POST-Anfragen, und Server können synchron oder über SSE-Streaming antworten. Er funktioniert hinter Load Balancern und unterstützt Standard-HTTP-Authentifizierung.

Wie viele MCP-Server gibt es?

Die Linux Foundation nannte 10.000+ aktive Server und 97 Millionen monatliche SDK-Downloads, als MCP im Dezember 2025 an AAIF übergeben wurde. Das Ökosystem umfasst Datenbanken, Code-Tools, SaaS-Integrationen, Suchmaschinen und Cloud-Infrastrukturanbieter.

Fazit

MCP ist in etwas mehr als einem Jahr von Anthropics Open-Source-Experiment zum Industriestandard für die Verbindung von KI-Modellen mit Tools geworden. Hier ist, was wichtig ist:

• MCP löst das M x N Problem -- ein Server funktioniert mit jedem kompatiblen Modell, ein Client funktioniert mit jedem Server
• Du kannst einen funktionierenden MCP-Server in unter 50 Zeilen Python (FastMCP) oder TypeScript bauen
• Nutze stdio für die Entwicklung, Streamable HTTP für die Produktion -- die Transport-Wahl ist einfach
• Sichere deine Server mit OAuth 2.1 -- 88% der aktuellen Implementierungen tun das nicht, und das ist ein echtes Risiko
• Das Ökosystem ist produktionsreif -- 10.000+ Server, alle großen LLMs, herstellerneutrale Governance unter der Linux Foundation

Mit Blick nach vorne konzentriert sich die 2026-Roadmap auf Agent-zu-Agent-Kommunikation über ein neues Tasks-Primitive, verbesserte Unternehmenssicherheit und MCP Apps für interaktive servergesteuerte UI. MCP ist nicht mehr nur ein Protokoll für Tool-Zugriff -- es wird zur Infrastrukturschicht für agentische KI.

Beginne mit dem Tutorial-Code oben, teste ihn im MCP Inspector und verbinde ihn mit Claude Desktop. Du wirst eine funktionierende MCP-Integration in unter einer Stunde haben.

Quellen

• MCP-Spezifikation (2025-11-25)
• MCP-Autorisierungsspezifikation
• MCP-Transportspezifikation
• MCP Inspector-Dokumentation
• Vorstellung des Model Context Protocol -- Anthropic
• MCP an die Linux Foundation spenden -- Anthropic
• Linux Foundation AAIF-Ankündigung
• Google Cloud MCP-Unterstützung
• FastMCP Python SDK
• MCP TypeScript SDK
• Astrix Security: Stand der MCP-Server-Sicherheit 2025
• MCP 2026-Roadmap