Model Context Protocol (MCP): Grundlagen verstehen

1. Das N-mal-M-Integrationsproblem und wie MCP es löst

Bevor das Model Context Protocol existierte, musste praktisch jede Anbindung eines externen Systems an einen KI-Assistenten von Grund auf neu gebaut werden. Ein Unternehmen mit einer internen Datenbank, einem Ticketing-System und einer Dokumentations-Suche brauchte für jeden Assistenten, der darauf zugreifen sollte, eine eigene, oft proprietäre Integration. Bei N Assistenten und M Werkzeugen entstehen so im schlimmsten Fall N mal M einzelne Integrationen, von denen jede gewartet, getestet und bei API-Änderungen aktualisiert werden muss. Dieses Muster ist aus klassischen Softwarearchitekturen bekannt und führt fast immer zu Wildwuchs.

Anthropic hat das Model Context Protocol im November 2024 als offenen Standard veröffentlicht, um genau dieses N-mal-M-Problem auf ein N-plus-M-Problem zu reduzieren. Statt jeder Kombination aus Assistent und Werkzeug eine eigene Brücke zu bauen, implementiert ein Werkzeuganbieter einmal einen MCP-Server, und jeder MCP-fähige Client, etwa Claude Desktop, Claude Code oder eine andere kompatible Anwendung, kann diesen Server ohne zusätzliche Anpassung nutzen. Der Vergleich mit USB-C, den Anthropic selbst verwendet, trifft den Kern: eine einheitliche Schnittstelle statt eines Kabelsalats aus Spezialadaptern.

2. Client-Server-Architektur: Host, Client, Server

MCP unterscheidet drei Rollen, die begrifflich sauber getrennt sind, auch wenn sie in der Praxis manchmal im selben Prozess laufen. Der Host ist die Anwendung, mit der ein Mensch tatsächlich interagiert, etwa Claude Desktop, Claude Code oder eine selbst gebaute Chat-Oberfläche. Der Host verwaltet einen oder mehrere Clients, wobei jeder Client eine eigene, zustandsbehaftete Eins-zu-eins-Verbindung zu genau einem Server hält. Der Server ist der Teil, der tatsächlich Zugriff auf ein externes System bereitstellt, etwa eine Datenbank, ein Ticketing-System oder eine Dateisammlung, und wird dabei völlig unabhängig vom konkreten Host implementiert.

Diese Trennung hat einen praktischen Grund: Ein Server muss nichts über Claude oder ein anderes Sprachmodell wissen, sondern beschreibt nur, welche Fähigkeiten er anbietet. Beim Verbindungsaufbau tauschen Client und Server in einem Handshake ihre Capabilities aus, sodass ein Client vorab weiß, ob ein Server Tools, Resources, Prompts oder eine Kombination davon unterstützt. Diese Kapselung ist zugleich eine Sicherheitsgrenze: Der Server kontrolliert genau, welche Operationen er zulässt, während der Host entscheidet, welchen Servern überhaupt vertraut wird.

3. JSON-RPC als Basis: Handshake und Capabilities

Auf der Übertragungsebene setzt MCP auf JSON-RPC 2.0, ein schlankes, seit Jahren etabliertes Protokoll für entfernte Prozeduraufrufe. Jede Nachricht ist entweder eine Anfrage mit eindeutiger ID und erwarteter Antwort, oder eine Notification ohne Antworterwartung. Diese Wahl ist bewusst konservativ: JSON-RPC ist einfach zu parsen, sprachunabhängig und in praktisch jeder Programmiersprache mit minimalem Aufwand implementierbar, was die Einstiegshürde für neue Server-Implementierungen niedrig hält.

Nach dem initialen Handshake, in dem Protokollversion und Capabilities ausgetauscht werden, ruft der Client typische Methoden wie tools/list, tools/call, resources/list oder prompts/get auf. Die Antwort auf tools/list zeigt exemplarisch, wie ein Server seine Fähigkeiten beschreibt: Jedes Tool liefert einen Namen, eine für das Sprachmodell verständliche Beschreibung und ein JSON-Schema für die erwarteten Parameter. Genau dieses Schema nutzt Claude, um zu entscheiden, ob und mit welchen Argumenten ein Tool zur Beantwortung einer Anfrage aufgerufen werden sollte.

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "search_products",
        "description": "Search products by SKU prefix and return name, price and stock status",
        "inputSchema": {
          "type": "object",
          "properties": {
            "sku_prefix": { "type": "string" },
            "limit": { "type": "integer", "default": 20 }
          },
          "required": ["sku_prefix"]
        }
      },
      {
        "name": "create_ticket",
        "description": "Create a new support ticket in the tracker",
        "inputSchema": {
          "type": "object",
          "properties": {
            "title": { "type": "string" },
            "description": { "type": "string" },
            "priority": { "type": "string", "enum": ["low", "medium", "high"] }
          },
          "required": ["title", "description", "priority"]
        }
      }
    ]
  }
}

4. Tools: Funktionen, die ein MCP-Server bereitstellt

Tools sind die aktivste Kategorie von MCP-Fähigkeiten: Funktionen mit klar definierten Parametern, die das Sprachmodell selbstständig aufrufen kann, um eine Aktion auszuführen oder Informationen zu beschaffen. Anders als bei einer statischen Wissensbasis entscheidet das Modell zur Laufzeit, basierend auf Namen, Beschreibung und Parameter-Schema eines Tools, ob ein Aufruf sinnvoll ist. Ein Tool kann rein lesend sein, etwa eine Produktsuche, oder einen Nebeneffekt auslösen, etwa das Anlegen eines Tickets, weshalb Host-Anwendungen für Letzteres in der Regel eine Bestätigung durch den Nutzer verlangen.

Das folgende Beispiel zeigt einen minimalen MCP-Server in Python mit dem offiziellen SDK, der eine schreibgeschützte Schnittstelle zu einer Magento-Produkttabelle bereitstellt. Die Funktion search_products wird über den Dekorator @mcp.tool() registriert; Docstring und Typannotationen werden automatisch in das JSON-Schema übersetzt, das der Client beim Handshake erhält. Diese Automatik ist einer der praktischen Vorteile von MCP gegenüber handgeschriebenen Funktionsbeschreibungen: Das Schema bleibt zwangsläufig synchron mit der tatsächlichen Implementierung, weil beides aus demselben Code entsteht.

#!/usr/bin/env python3
"""MCP server exposing a read-only interface to a Magento product table."""
from mcp.server.fastmcp import FastMCP
import mysql.connector

mcp = FastMCP("magento-catalog")


def get_connection():
    """Open a connection using a read-only database user."""
    return mysql.connector.connect(
        host="localhost",
        user="readonly_user",
        password="change-me",
        database="magento",
    )


@mcp.tool()
def search_products(sku_prefix: str, limit: int = 20) -> list[dict]:
    """Search products by SKU prefix and return name, price and stock status."""
    conn = get_connection()
    cursor = conn.cursor(dictionary=True)
    cursor.execute(
        "SELECT sku, name, price FROM catalog_product_flat_1 "
        "WHERE sku LIKE %s LIMIT %s",
        (f"{sku_prefix}%", limit),
    )
    rows = cursor.fetchall()
    cursor.close()
    conn.close()
    return rows


@mcp.resource("schema://catalog_product_flat")
def get_schema() -> str:
    """Expose the flat product table schema as read-only context."""
    return "sku VARCHAR(64), name VARCHAR(255), price DECIMAL(12,4), status INT"


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

5. Resources und Prompts: Kontext und Vorlagen bereitstellen

Neben Tools kennt MCP zwei weitere Fähigkeitstypen, die häufig unterschätzt werden, weil kein Sprachmodell sie im Sinne einer Funktion aufruft. Resources sind adressierbare, meist lesende Datenquellen, jede mit einer eindeutigen URI, etwa schema://catalog_product_flat oder file:///docs/deployment.md. Sie funktionieren konzeptionell wie ein GET-Request: kein Seiteneffekt, austauschbarer Inhalt, wiederholt abrufbar. Der entscheidende Unterschied zu Tools liegt darin, wer die Entscheidung trifft: Resources werden typischerweise von der Host-Anwendung oder vom Nutzer ausgewählt und als Kontext angehängt, während das Sprachmodell selbst nicht aktiv nach ihnen sucht.

Prompts sind vordefinierte, parametrisierbare Vorlagen, die ein Server bereitstellt und die der Nutzer gezielt auslöst, vergleichbar mit einem Slash-Befehl. Ein Dokumentations-Server könnte etwa einen Prompt summarize-release-notes anbieten, der als Argument eine Versionsnummer erwartet und daraus eine vollständige, vorformulierte Anfrage an das Modell zusammensetzt. Diese Dreiteilung in Tools, Resources und Prompts spiegelt letztlich wider, wer die Kontrolle über eine Aktion hat: das Modell, die Anwendung oder der Mensch, und macht MCP-Server dadurch deutlich vorhersehbarer als eine einzige, undifferenzierte Funktionsliste.

6. Transport-Mechanismen: stdio, HTTP und Streaming

MCP trennt bewusst das Protokoll von der Transportschicht, sodass dieselbe JSON-RPC-Nachrichtenstruktur über unterschiedliche Kanäle laufen kann. Der stdio-Transport ist der einfachste Fall: Der Host startet den Server als lokalen Kindprozess und kommuniziert über Standard-Input und Standard-Output. Das eignet sich hervorragend für Werkzeuge, die ohnehin lokal laufen sollen, etwa ein Dateisystem-Zugriff oder eine lokale Entwicklungsdatenbank, weil keinerlei Netzwerkexposition entsteht und die Lebensdauer des Servers an die Sitzung des Hosts gekoppelt ist.

Für Server, die unabhängig vom Host und potenziell von mehreren Clients gleichzeitig genutzt werden sollen, etwa ein zentraler Ticketing-Server für ein ganzes Team, definiert MCP einen HTTP-basierten Transport mit Streaming-Unterstützung für serverseitig initiierte Nachrichten. Dieser Weg bringt zusätzliche Anforderungen an Authentifizierung mit sich, üblicherweise über OAuth 2.1, weil der Server nun über ein Netzwerk erreichbar ist und nicht mehr implizit durch den lokalen Prozessstart abgesichert wird. Zum Testen und Debuggen beider Transportarten eignet sich der offizielle MCP Inspector, der Tool-Aufrufe interaktiv nachvollziehbar macht, bevor ein Server produktiv an einen Client angebunden wird.

#!/usr/bin/env bash
# Test an MCP server via stdio using the official inspector
npx @modelcontextprotocol/inspector python3 ./mcp-servers/catalog_server.py

# List the tools a running MCP server exposes over HTTP transport
curl -s -X POST https://mcp.internal.mironsoft.de/jira \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | jq '.result.tools[].name'

# Register a local MCP server with Claude Code (stdio transport)
claude mcp add magento-catalog -- python3 ./mcp-servers/catalog_server.py

# Register a remote MCP server reachable over HTTP transport
claude mcp add docs-search --transport http https://mcp.internal.mironsoft.de/docs

7. Praxisbeispiele: Datenbank-, Ticketing- und Dokumentations-Server

Drei wiederkehrende Beispiele zeigen gut, wie unterschiedlich MCP-Server in der Praxis aussehen können, obwohl sie demselben Protokoll folgen. Ein Datenbank-Server kapselt typischerweise wenige, eng begrenzte Abfragen statt eines generischen SQL-Zugriffs, etwa Produktsuche nach SKU oder Bestandsabfrage, und läuft meist lokal über stdio mit einem schreibgeschützten Datenbankbenutzer. Ein Ticketing-Server für Systeme wie Jira oder GitHub Issues bildet dagegen typische Workflow-Aktionen als Tools ab, etwa Ticket anlegen, Status ändern oder Kommentar hinzufügen, und läuft häufig als zentraler HTTP-Server, weil mehrere Personen im Team ihn gleichzeitig nutzen sollen.

Ein Dokumentations-Such-Server exponiert meist eine Kombination aus einem Such-Tool, das eine semantische oder Volltextsuche über interne Handbücher, Runbooks oder Wikis ausführt, und Resources für einzelne Dokumente, die dann als Kontext angehängt werden können. Das folgende Beispiel zeigt einen Ausschnitt aus einem Ticketing-Server in Node.js mit dem offiziellen TypeScript-SDK: Das Tool create_ticket validiert seine Parameter über ein Zod-Schema, ruft die interne REST-API des Trackers auf und gibt dem Modell eine kurze Bestätigungsnachricht mit der neu erzeugten Ticket-ID zurück.

// mcp-jira-server.js: expose a ticketing system as MCP tools
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: "jira-tickets", version: "1.0.0" });

server.tool(
  "create_ticket",
  "Create a new support ticket in the tracker",
  {
    title: z.string(),
    description: z.string(),
    priority: z.enum(["low", "medium", "high"]),
  },
  async ({ title, description, priority }) => {
    const response = await fetch("https://jira.internal/api/issues", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ title, description, priority }),
    });
    const ticket = await response.json();
    return {
      content: [{ type: "text", text: `Created ticket ${ticket.key}` }],
    };
  }
);

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

8. Sicherheit und Vertrauen: Was MCP nicht automatisch löst

MCP standardisiert, wie ein Assistent auf externe Systeme zugreift, trifft aber keine Aussage darüber, ob dieser Zugriff sicher ist. Ein Server erhält genau die Rechte, die sein zugrunde liegender Code und die verwendeten Zugangsdaten mitbringen; ein Datenbank-Server mit einem Benutzer, der Schreibrechte auf die gesamte Datenbank hat, kann theoretisch weit mehr als nur Produkte suchen, selbst wenn nur ein einziges lesendes Tool exponiert wird. Ebenso kann Inhalt, der über eine Resource eingelesen wird, etwa eine manipulierte Wiki-Seite, versuchen, das Modell über eine Prompt-Injection zu unerwünschten Tool-Aufrufen zu bewegen.

Die praktischen Gegenmaßnahmen unterscheiden sich kaum von denen für andere externe Abhängigkeiten: Datenbankbenutzer mit dem geringsten notwendigen Rechteumfang anlegen, Quellcode eines Drittanbieter-Servers vor der Installation prüfen, und Host-Anwendungen wie Claude Code nutzen, die vor potenziell folgenreichen Tool-Aufrufen eine Bestätigung verlangen, statt jeden Aufruf blind auszuführen. Für HTTP-Server kommt Netzwerksegmentierung hinzu, damit ein kompromittierter Server nicht automatisch Zugriff auf weitere interne Systeme erhält. MCP-Server sollten organisatorisch wie jede andere Softwareabhängigkeit behandelt werden, inklusive Versionierung, Updates und gelegentlicher Sicherheitsüberprüfung.

9. MCP in Claude Code und Claude Desktop einrichten

Claude Code und Claude Desktop lesen MCP-Server-Definitionen aus einer .mcp.json-Datei oder aus der über claude mcp add verwalteten Konfiguration. Jeder Eintrag beschreibt, wie ein Server gestartet wird, entweder als lokaler Prozess mit Kommando und Argumenten für stdio, oder als URL für einen entfernten HTTP-Server. Claude Code unterscheidet dabei drei Sichtbarkeits-Scopes: lokal für nur auf dem eigenen Rechner sichtbare Server, projektweit für Server, die im Repository versioniert und mit dem Team geteilt werden, und nutzerweit für Server, die über alle Projekte hinweg verfügbar sein sollen.

{
  "mcpServers": {
    "magento-catalog": {
      "command": "python3",
      "args": ["./mcp-servers/catalog_server.py"],
      "env": { "DB_HOST": "localhost" }
    },
    "docs-search": {
      "command": "npx",
      "args": ["-y", "@mironsoft/mcp-docs-search"]
    },
    "jira-tickets": {
      "url": "https://mcp.internal.mironsoft.de/jira",
      "transport": "http"
    }
  }
}

Die folgende Übersicht ordnet den Aufwand von MCP gegenüber einer klassischen Custom-Integration pro Werkzeug ein.

In der Praxis kombinieren viele Setups beide Ansätze: schnelle, lokale MCP-Server für Entwicklungswerkzeuge wie Datenbank- oder Dateisystemzugriff, und weiterhin direkte API-Aufrufe für einmalige Spezialfälle, die kein zweiter Client jemals wiederverwenden wird.

10. Zusammenfassung

Das Model Context Protocol löst ein strukturelles Problem der KI-gestützten Entwicklung: Ohne einen gemeinsamen Standard müsste jede Kombination aus Assistent und externem Werkzeug einzeln integriert werden. MCP reduziert diesen Aufwand, indem Server ihre Fähigkeiten einmal über Tools, Resources und Prompts beschreiben und jeder MCP-fähige Client, darunter Claude Code und Claude Desktop, sie ohne zusätzliche Anpassung nutzen kann. Die Trennung in Host, Client und Server sorgt dabei für klare Verantwortlichkeiten: Der Server kennt kein Sprachmodell, der Client kennt keine Geschäftslogik-Details, und der Host entscheidet, welchen Servern überhaupt vertraut wird.

Wichtig bleibt, dass MCP ein Kommunikationsprotokoll ist, kein Sicherheitsversprechen. Zugriffsrechte, Prompt-Injection-Risiken und die Vertrauenswürdigkeit von Drittanbieter-Servern müssen weiterhin bewusst adressiert werden, mit denselben Mitteln wie bei jeder anderen externen Abhängigkeit. Für Teams, die mehrere interne Systeme wie Datenbanken, Ticketing und Dokumentation an Claude anbinden wollen, ist MCP inzwischen der praktikabelste Standardweg, weil die investierte Arbeit in einen Server über Projekte und sogar über verschiedene KI-Anwendungen hinweg wiederverwendbar bleibt.

11. FAQ: Model Context Protocol (MCP)