MCP-Server einrichten: Anleitung in 12 Schritten

Wer im September 2026 einen KI-Agenten baut, kommt an einer Abkürzung kaum noch vorbei: MCP. Das Model Context Protocol hat sich seit seiner Vorstellung durch Anthropic zum gemeinsamen Anschluss zwischen Sprachmodellen und der echten Welt entwickelt, von der eigenen Datenbank bis zum firmeninternen Ticketsystem. Allein der Suchbegriff “mcp server” kommt hierzulande laut aktuellen Keyword-Daten auf rund 14.800 Suchanfragen pro Monat, ein deutliches Zeichen dafür, dass Entwicklerinnen und Entwickler das Thema gerade in großer Zahl selbst anpacken wollen. Diese Anleitung zeigt in 12 Schritten, wie ein eigener MCP-Server entsteht, von der ersten Python-Datei über den Anschluss an Claude Desktop bis zum Deployment in Docker.

Am Ende steht ein vollständiges, lauffähiges Beispielprojekt, ein einfacher Wetter-Server mit eigenem Werkzeug, eigener Ressource und eigener Prompt-Vorlage, das sich direkt als Startpunkt für größere Vorhaben eignet. Unterwegs geht es außerdem um typische Stolperfallen, acht konkrete Troubleshooting-Fälle und die Sicherheitsfragen, die mit dem schnellen Wachstum des MCP-Ökosystems mittlerweile unweigerlich einhergehen.

Was ist das Model Context Protocol (MCP)?

MCP ist ein offener Standard, den Anthropic Ende 2024 veröffentlicht hat, um KI-Anwendungen und externe Werkzeuge über eine einheitliche Schnittstelle zu verbinden. Anthropic selbst beschreibt das Protokoll so: “The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools” (Anthropic, Ankündigung). Praktisch bedeutet das: Statt für jede Kombination aus Modell und Datenquelle eine eigene Integration zu schreiben, sprechen beide Seiten dieselbe Sprache.

Die Architektur folgt einem einfachen Client-Server-Muster. Ein MCP-Server stellt Fähigkeiten bereit, ein MCP-Client (etwa Claude Desktop, ein IDE-Plugin oder ein eigener Agent) verbindet sich damit. Laut offizieller Spezifikation kann ein Server drei Arten von Fähigkeiten anbieten: “Resources: Context and data, for the user or the AI model to use; Prompts: Templated messages and workflows for users; Tools: Functions for the AI model to execute” (MCP-Spezifikation). Tools sind dabei die praktisch wichtigste Kategorie, weil das Sprachmodell sie eigenständig aufruft, um zum Beispiel eine Datenbankabfrage auszuführen oder eine E-Mail zu verschicken.

Wichtig für die Praxis: Die MCP-Dokumentation wird inzwischen datiert versioniert. Die aktuelle Entwickler-Dokumentation liegt unter dem Pfad docs/2026-07-28, was auf eine grundlegende Überarbeitung im Sommer 2026 hindeutet, bei der das Protokoll stärker in Richtung eines zustandslosen Request-Response-Modells verschoben wurde. Für neue Projekte lohnt sich deshalb ein Blick in die jeweils aktuellste Dokumentationsversion, bevor der erste Server geschrieben wird.

Ein weiterer Punkt sorgt anfangs oft für Verwirrung: MCP ersetzt nicht das Sprachmodell selbst, sondern sitzt eine Ebene darunter. Das Modell trifft weiterhin alle inhaltlichen Entscheidungen, MCP liefert lediglich einen standardisierten Weg, wie das Modell an frische Daten oder Handlungsmöglichkeiten kommt. Ein MCP-Server kennt insofern kein “Denken”, er stellt nur Funktionen, Dateien und Vorlagen bereit und überlässt die Entscheidung, wann und wie sie genutzt werden, komplett dem anfragenden Client.

Auf technischer Ebene laufen alle Nachrichten zwischen Client und Server als JSON-RPC-Aufrufe, ein seit Jahren etabliertes, leichtgewichtiges Format für entfernte Prozeduraufrufe. Wer schon einmal mit klassischen RPC-Systemen gearbeitet hat, findet sich hier schnell zurecht: Jede Anfrage besitzt eine eindeutige ID, eine Methode und optionale Parameter, jede Antwort verweist über dieselbe ID zurück auf die passende Anfrage. Das SDK verbirgt diese Details zwar meist hinter Dekoratoren wie @mcp.tool(), für die Fehlersuche bei komplexeren Servern lohnt sich aber ein Blick auf die rohen JSON-RPC-Nachrichten, etwa über den weiter unten vorgestellten MCP Inspector.

Warum MCP-Server 2026 zum Standard für KI-Agenten werden

Was 2024 als Nischenprotokoll für Claude-Nutzer startete, ist 2026 in der Breite angekommen. Das offizielle Registry-Portal unter registry.modelcontextprotocol.io ging im September 2025 in den Preview-Betrieb und dient inzwischen als kanonischer Namespace, über den sich Server unter Reverse-DNS-Namen eintragen. Nach einer im September 2026 veröffentlichten Bestandsaufnahme zählte die offizielle Registry zu diesem Zeitpunkt bereits über 22.000 aktive Servereinträge, ein Sprung gegenüber rund 9.600 Einträgen im Mai desselben Jahres. Rechnet man Drittanbieter-Verzeichnisse wie Smithery, mcp.so, Glama und PulseMCP hinzu, kommen laut einem Bericht der Linux Foundation zum “State of MCP” mehrere zehntausend zusätzliche Serverlistings zusammen, wenngleich diese Zahlen wegen Doppelzählungen zwischen Verzeichnissen nur als grobe Größenordnung taugen.

Auch etablierte Softwarehäuser ziehen 2026 nach. DocuSign kündigte am 4. September 2026 an, seinen bestehenden MCP-Server ab dem 30. September für praktisch jede Agenten-Plattform zu öffnen, direkt angebunden an die hauseigene KI namens DocuSign Iris. Nur wenige Tage später, am 7. September 2026, startete auch Process Street einen gehosteten MCP-Server unter mcp.process.st, über den Assistenten wie Claude oder ChatGPT auf Workflows, Aufgaben und Datensätze zugreifen können, ohne dass sich jemand manuell im Tool einloggen muss. Diese Beispiele zeigen den eigentlichen Reiz von MCP: Ein einmal gebauter Server lässt sich an praktisch jeden MCP-fähigen Client anschließen, egal ob das Claude, ChatGPT, Gemini oder Microsoft Copilot Studio heißt.

Für Entwicklerteams in Deutschland und der gesamten DACH-Region ergibt sich daraus ein handfester Vorteil: Wer heute einen MCP-Server für die eigene interne API baut, muss morgen keine zweite Integration für ein anderes KI-Tool schreiben. Das senkt den Wartungsaufwand spürbar und macht MCP zu einer Investition, die über den Hype einzelner Chatbot-Anbieter hinaus Bestand hat. Wer bereits mit Agenten-Frameworks wie LangChain oder CrewAI arbeitet, kann MCP-Server zudem direkt als zusätzliche Werkzeugquelle einbinden, statt eigene Adapter zu pflegen.

In der Praxis tauchen MCP-Server inzwischen in ganz unterschiedlichen Einsatzfeldern auf. Support-Teams binden über MCP das eigene Ticketsystem an einen Chat-Assistenten an, damit dieser offene Vorgänge nachschlagen kann, ohne dass jemand Zugangsdaten für ein separates Dashboard weitergeben muss. DevOps-Teams nutzen Server, die Kubernetes- oder Cloud-Befehle kapseln, sodass ein Agent Deployments auslösen oder Logs durchsuchen kann, allerdings nur innerhalb der Grenzen, die der Server selbst vorgibt. Und Data-Teams verbinden Sprachmodelle über MCP direkt mit Data-Warehouses, um Kennzahlenabfragen in natürlicher Sprache zu ermöglichen, ohne SQL-Zugriff pauschal für jede Nutzerin und jeden Nutzer zu öffnen.

MCP versus klassisches Function Calling: Der Unterschied

Wer bereits mit der Function-Calling-Funktion von OpenAI oder Anthropic gearbeitet hat, fragt sich zu Recht, wo der Mehrwert von MCP eigentlich liegt. Function Calling beschreibt Werkzeuge direkt im Prompt einer einzelnen API-Anfrage, jede Integration bleibt an genau diese eine Anwendung gebunden. MCP verschiebt dieselbe Idee eine Ebene höher: Ein Server beschreibt seine Werkzeuge einmal, unabhängig vom aufrufenden Client, und macht sie dadurch für beliebig viele Anwendungen gleichzeitig nutzbar.

Merkmal	Klassisches Function Calling	Model Context Protocol
Wiederverwendbarkeit	An eine API-Anfrage und einen Anbieter gebunden	Ein Server, beliebig viele Clients
Discovery	Werkzeuge müssen bei jeder Anfrage neu übergeben werden	Client fragt Werkzeuge beim Verbindungsaufbau selbstständig ab
Zusätzliche Fähigkeiten	Nur Funktionsaufrufe	Tools, Resources und Prompts als getrennte Kategorien
Transport	Reiner HTTP-Request an den jeweiligen Modell-Anbieter	stdio für lokal, Streamable HTTP für entfernte Server
Ökosystem	Anbieterspezifisch, kaum Wiederverwendung	Über 22.000 aktive Server in der offiziellen Registry (Stand 19. August 2026)

In der Praxis schließen sich beide Ansätze übrigens nicht aus. Viele MCP-SDKs übersetzen registrierte Tools intern ohnehin in das Function-Calling-Format des jeweiligen Modells, bevor sie überhaupt beim Sprachmodell ankommen. MCP übernimmt dabei lediglich die Rolle der Verpackung: Ein Tool wird einmal geschrieben und beliebig oft wiederverwendet, während die eigentliche Modell-Kommunikation weiterhin über bekannte Mechanismen läuft.

Voraussetzungen: Software, Versionen und Accounts

Bevor der erste Server entsteht, sollten folgende Werkzeuge bereitstehen. Die Tabelle listet die Mindestversionen, wie sie aktuell von den offiziellen SDKs vorausgesetzt werden.

Werkzeug	Mindestversion	Zweck in diesem Tutorial
Python	3.10 oder neuer	Laufzeitumgebung für den Python-MCP-Server (Paket `mcp`, aktuell Version 2.2.0)
Node.js	18 oder neuer	Laufzeitumgebung für die TypeScript-Variante (Paket `@modelcontextprotocol/sdk`, aktuell Version 1.30.0)
uv oder pip	aktuell	Python-Paketverwaltung, uv wird von Anthropic in den offiziellen Beispielen bevorzugt
Claude Desktop	aktuelle Version	MCP-Client zum Testen der Server-Anbindung
MCP Inspector	2.6.0	Grafisches und CLI-Testwerkzeug, per `npx` ohne Installation nutzbar
Docker	aktuell	Optional für das produktive Deployment in Schritt 12

Grundkenntnisse in Python oder TypeScript reichen aus, tiefes Wissen über Sprachmodelle ist nicht nötig. Wer bereits eine Claude-API-Anbindung eingerichtet hat, wird die Terminologie rund um Tools und Systemprompts wiedererkennen.

Schritt-für-Schritt-Anleitung: Der erste MCP-Server in 12 Schritten

Die folgenden zwölf Schritte führen von einer leeren Projektmappe zu einem lauffähigen, produktionsnah abgesicherten MCP-Server. Jeder Schritt baut auf dem vorherigen auf, kann aber auch einzeln nachvollzogen werden.

Schritt 1: Projektordner und virtuelle Umgebung anlegen

Zuerst braucht es einen sauberen Projektordner mit isolierter Python-Umgebung, damit Paketversionen nicht mit anderen Projekten kollidieren.

mkdir mcp-wetter-server
cd mcp-wetter-server
python3 -m venv .venv
source .venv/bin/activate  # unter Windows: .venv\Scripts\activate

Wer stattdessen uv nutzt, spart sich diesen Schritt weitgehend, da uv run Umgebungen automatisch verwaltet. Für diese Anleitung reicht die klassische venv-Variante, sie funktioniert auf jedem System gleich.

Schritt 2: Das offizielle Python-SDK installieren

Das Python-SDK des MCP-Projekts ist unter dem Paketnamen mcp auf PyPI verfügbar und bringt in der CLI-Variante gleich das nötige Kommandozeilenwerkzeug mit.

pip install "mcp[cli]"
pip install httpx  # für HTTP-Anfragen im Beispiel-Tool

Das zugrunde liegende Repository modelcontextprotocol/python-sdk zählt aktuell mehr als 24.300 Sterne auf GitHub, das breitere Repository modelcontextprotocol/servers mit Referenzimplementierungen kommt sogar auf über 90.300 Sterne, ein guter Indikator für die Reife und Community-Größe hinter dem Projekt.

Schritt 3: Den Basis-Server schreiben

Jetzt entsteht die zentrale Serverdatei. Das SDK stellt dafür die Klasse FastMCP bereit, die viel Boilerplate-Code abnimmt.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("wetter")

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

Dieser Server tut noch nichts Sichtbares, aber er startet bereits sauber über den Standard-Ein- und Ausgabekanal (stdio), dem einfachsten der beiden von der Spezifikation vorgesehenen Transportwege.

Schritt 4: Ein Tool definieren, das das Modell aufrufen kann

Tools sind Funktionen, die das Sprachmodell eigenständig ausführt. Der Dekorator @mcp.tool() registriert eine normale Python-Funktion als aufrufbares Werkzeug, inklusive automatisch generiertem JSON-Schema aus den Typannotationen.

import httpx

@mcp.tool()
async def get_forecast(lat: float, lon: float) -> str:
    """Gibt die Wettervorhersage für einen Ort zurück.

    Args:
        lat: Breitengrad des Ortes
        lon: Längengrad des Ortes
    """
    url = f"https://api.open-meteo.com/v1/forecast?latitude={lat}&longitude={lon}¤t=temperature_2m"
    async with httpx.AsyncClient() as client:
        response = await client.get(url, timeout=10.0)
        response.raise_for_status()
        data = response.json()
    temp = data["current"]["temperature_2m"]
    return f"Aktuelle Temperatur: {temp} Grad Celsius"

Der Docstring ist kein Kommentar zum Schmuck: Das SDK reicht ihn als Tool-Beschreibung an das Sprachmodell weiter, das anhand dieses Textes entscheidet, wann das Werkzeug sinnvoll ist. Eine präzise Beschreibung ist damit direkt für die Zuverlässigkeit des Agenten verantwortlich.

Für Tools mit mehr Gewicht als eine simple Wetterabfrage lohnt sich zusätzliche Eingabevalidierung, statt sich allein auf das automatisch generierte JSON-Schema zu verlassen. Wird beispielsweise ein negativer Breitengrad außerhalb des gültigen Bereichs übergeben, sollte die Funktion das selbst abfangen und eine verständliche Fehlermeldung als Text zurückgeben, statt eine rohe Python-Exception nach außen durchzureichen. Das Modell kann mit einer klaren Fehlermeldung wie “Ungültiger Breitengrad, Wert muss zwischen -90 und 90 liegen” umgehen und den Nutzer entsprechend informieren, mit einem nackten Stacktrace dagegen nicht.

Schritt 5: Resources für strukturierten Datenzugriff hinzufügen

Neben Tools kennt MCP auch Resources, also dateiartige Daten, die ein Client lesen kann, ohne dass das Modell dafür zwingend eine Funktion aufrufen muss. Sie eignen sich für Kontext, der eher passiv bereitgestellt als aktiv abgefragt wird.

@mcp.resource("wetter://stationen")
def liste_stationen() -> str:
    """Liefert eine Liste bekannter Wetterstationen als Referenz."""
    return "Berlin, Hamburg, München, Köln, Frankfurt am Main"

Der URI-artige Bezeichner wetter://stationen identifiziert die Ressource eindeutig. Clients können solche Ressourcen auflisten und bei Bedarf einbinden, etwa um dem Modell eine feste Liste gültiger Städtenamen an die Hand zu geben.

Schritt 6: Prompts als wiederverwendbare Vorlagen bereitstellen

Die dritte Fähigkeitskategorie sind Prompts, vorformulierte Nachrichtenvorlagen, die Nutzerinnen und Nutzer direkt auswählen können, statt jedes Mal denselben Text neu zu tippen.

@mcp.prompt()
def wetterbericht(stadt: str) -> str:
    """Erstellt einen kompakten Wetterbericht für eine Stadt."""
    return f"Erstelle einen kurzen, freundlichen Wetterbericht für {stadt} auf Deutsch."

Prompts erscheinen in Claude Desktop als Schnellauswahl über ein kleines Symbol im Eingabefeld. Für wiederkehrende Aufgaben, etwa standardisierte Berichte, sparen sie spürbar Tipparbeit.

Schritt 7: Den Server lokal mit dem MCP Inspector testen

Vor dem Anschluss an einen echten Client lohnt sich ein Test mit dem offiziellen MCP Inspector, der als npm-Paket @modelcontextprotocol/inspector in Version 2.6.0 vorliegt und ganz ohne feste Installation über npx läuft.

# Grafische Oberfläche im Browser
npx @modelcontextprotocol/inspector python server.py

# Alternative: reine Kommandozeile für CI-Pipelines
npx @modelcontextprotocol/inspector --cli python server.py

Der Inspector öffnet eine lokale Weboberfläche, in der sich alle registrierten Tools, Resources und Prompts einzeln aufrufen lassen. Das ist der schnellste Weg, um Tippfehler in Typannotationen oder fehlerhafte Rückgabewerte zu finden, bevor überhaupt ein KI-Modell involviert ist.

Schritt 8: MCP-Server mit Claude Desktop verbinden

Damit Claude Desktop den Server findet, muss er in der Konfigurationsdatei eingetragen werden. Der Speicherort unterscheidet sich je nach Betriebssystem.

Betriebssystem	Pfad der Konfigurationsdatei
macOS	`~/Library/Application Support/Claude/claude_desktop_config.json`
Windows	`%APPDATA%\Claude\claude_desktop_config.json`
Linux	`~/.config/Claude/claude_desktop_config.json`

{
  "mcpServers": {
    "wetter": {
      "command": "/ABSOLUTER/PFAD/ZUM/PROJEKT/.venv/bin/python",
      "args": [
        "/ABSOLUTER/PFAD/ZUM/PROJEKT/server.py"
      ]
    }
  }
}

Nach dem Speichern muss Claude Desktop komplett neu gestartet werden, ein einfaches Schließen des Fensters reicht oft nicht. Erscheint danach ein kleines Hammer-Symbol im Eingabefeld, hat der Client den Server erfolgreich geladen und die registrierten Tools stehen zur Auswahl.

Bleibt das Symbol aus, lohnt sich ein Blick in die Log-Dateien von Claude Desktop, die unter macOS im Ordner ~/Library/Logs/Claude und unter Windows im Ordner %APPDATA%\Claude\logs abgelegt werden. Dort protokolliert der Client jeden Startversuch eines MCP-Servers samt eventueller Fehlermeldung, etwa wenn der hinterlegte Pfad nicht existiert. Diese Logs sind meist der schnellere Weg zur Ursache als reines Ausprobieren verschiedener Konfigurationen.

Schritt 9: Von stdio auf Streamable HTTP umstellen

Der stdio-Transport eignet sich nur für lokal laufende Prozesse. Soll der Server dagegen im Netzwerk oder über das Internet erreichbar sein, kommt der zweite von der Spezifikation vorgesehene Transportweg zum Einsatz: Streamable HTTP. Er ersetzt den älteren HTTP-plus-SSE-Transport aus Protokollversion 2024-11-05 vollständig.

if __name__ == "__main__":
    mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

Ein entfernter MCP-Server verhält sich damit im Betrieb wie ein gewöhnlicher HTTP-Dienst und lässt sich hinter bestehender API-Infrastruktur, Load-Balancern und Reverse-Proxys betreiben, ohne dass Sonderregeln für WebSockets oder langlebige Verbindungen nötig wären.

Schritt 10: TypeScript-Variante mit Node.js aufsetzen

Wer lieber im JavaScript- oder TypeScript-Ökosystem bleibt, findet mit @modelcontextprotocol/sdk (aktuell Version 1.30.0, Node.js ab Version 18 vorausgesetzt) ein funktional gleichwertiges Paket.

npm install @modelcontextprotocol/sdk zod

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: "wetter", version: "1.0.0" });

server.tool(
  "get_forecast",
  { lat: z.number(), lon: z.number() },
  async ({ lat, lon }) => {
    const res = await fetch(
      `https://api.open-meteo.com/v1/forecast?latitude=${lat}&longitude=${lon}¤t=temperature_2m`
    );
    const data = await res.json();
    return {
      content: [{ type: "text", text: `Aktuelle Temperatur: ${data.current.temperature_2m} Grad` }]
    };
  }
);

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

Python und TypeScript sind funktional gleichwertig, Teams entscheiden meist danach, welche Sprache im übrigen Backend bereits dominiert. Wer ohnehin mehrere Sprachmodell-Anbieter parallel anspricht, kann einen so gebauten MCP-Server anschließend problemlos mit einem Router wie LiteLLM kombinieren, ohne den Server selbst anzupassen.

Schritt 11: Authentifizierung und Zugriffskontrolle einrichten

Sobald ein Server per Streamable HTTP erreichbar ist, braucht er einen Schutz gegen unautorisierte Zugriffe. Für lokale stdio-Server übernimmt das Betriebssystem diese Aufgabe implizit, für Remote-Server nicht.

from starlette.middleware import Middleware
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.responses import JSONResponse
import os

class TokenAuthMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        token = request.headers.get("authorization", "").removeprefix("Bearer ")
        if token != os.environ.get("MCP_AUTH_TOKEN"):
            return JSONResponse({"error": "unauthorized"}, status_code=401)
        return await call_next(request)

Diese einfache Token-Prüfung ist ein Mindestmaß, kein Ersatz für einen vollwertigen OAuth-Fluss. Für produktive Umgebungen mit mehreren Nutzergruppen lohnt sich ein Blick in die jeweils aktuelle Sicherheits-Dokumentation des SDKs, da sich die Details zur Autorisierung zwischen Spezifikationsversionen bereits mehrfach verschoben haben.

Schritt 12: Server produktiv deployen mit Docker

Für den Betrieb außerhalb des eigenen Laptops empfiehlt sich ein Container, der Abhängigkeiten sauber kapselt und sich auf jedem Server gleich verhält.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY server.py .
EXPOSE 8000
CMD ["python", "server.py"]

docker build -t mcp-wetter-server .
docker run -d -p 8000:8000 -e MCP_AUTH_TOKEN=geheimestoken mcp-wetter-server

Damit läuft der Server unabhängig vom eigenen Rechner weiter und lässt sich hinter einem Reverse-Proxy mit TLS-Zertifikat ins Netz stellen, ganz ähnlich wie bei jedem anderen containerisierten Webdienst.

Betreiben mehrere Teams unterschiedliche MCP-Server, zahlt es sich meist aus, jeden Server als eigenen Container mit eigenem Port zu führen, statt mehrere Server in einem gemeinsamen Prozess zu bündeln. Ein Absturz in einem Server reißt so nicht automatisch alle anderen mit. Ein einfaches docker-compose.yml mit einem Service pro Server hält die Übersicht auch dann noch überschaubar, wenn im Laufe der Zeit weitere Werkzeuge dazukommen.

Komplettes Beispielprojekt: Ein Wetter-MCP-Server

Wer die einzelnen Schritte zusammensetzt, erhält folgende vollständige Serverdatei. Sie kombiniert ein Tool, eine Resource und einen Prompt in einem lauffähigen Skript und dient als Ausgangspunkt für eigene Erweiterungen.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("wetter")

@mcp.tool()
async def get_forecast(lat: float, lon: float) -> str:
    """Gibt die aktuelle Temperatur für Koordinaten zurück.

    Args:
        lat: Breitengrad
        lon: Längengrad
    """
    url = (
        f"https://api.open-meteo.com/v1/forecast"
        f"?latitude={lat}&longitude={lon}¤t=temperature_2m"
    )
    async with httpx.AsyncClient() as client:
        response = await client.get(url, timeout=10.0)
        response.raise_for_status()
        data = response.json()
    return f"Aktuelle Temperatur: {data['current']['temperature_2m']} Grad Celsius"

@mcp.resource("wetter://stationen")
def liste_stationen() -> str:
    """Bekannte Wetterstationen als Referenzliste."""
    return "Berlin, Hamburg, München, Köln, Frankfurt am Main"

@mcp.prompt()
def wetterbericht(stadt: str) -> str:
    """Erstellt eine Vorlage für einen kurzen Wetterbericht."""
    return f"Erstelle einen kurzen, freundlichen Wetterbericht für {stadt} auf Deutsch."

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

Nach dem Start über python server.py und dem Eintrag in claude_desktop_config.json kann eine Unterhaltung in Claude Desktop wie folgt aussehen: Die Nutzerin fragt “Wie warm ist es gerade in Hamburg?”, Claude erkennt anhand der Tool-Beschreibung, dass get_forecast passt, fragt nach Koordinaten oder schätzt sie selbst, ruft das Tool auf und antwortet anschließend in normaler Sprache mit dem Ergebnis. Der komplette Umweg über eine eigene API-Integration entfällt.

Von hier aus lässt sich das Projekt in kleinen Schritten erweitern. Ein zweites Tool get_alerts, das amtliche Unwetterwarnungen abfragt, ergänzt den Server um einen zweiten Anwendungsfall, ohne die bestehende Struktur zu verändern. Wer die Daten zusätzlich zwischenspeichern will, um nicht bei jeder Anfrage erneut die externe API zu belasten, kann einen einfachen In-Memory-Cache mit kurzer Gültigkeitsdauer vor den HTTP-Aufruf schalten. Beide Erweiterungen folgen demselben Muster wie das erste Tool: eine klar benannte Funktion, ein präziser Docstring und ein sauber behandelter Fehlerfall.

Häufige Stolperfallen beim Aufbau eines MCP-Servers

Die meisten Probleme beim ersten MCP-Server tauchen nicht im Code selbst auf, sondern in der Umgebung drumherum: falsche Pfade, vergessene Neustarts oder zu großzügig vergebene Rechte. Die folgende Liste sammelt die Fehler, die in Praxisberichten und Community-Foren am häufigsten genannt werden.

Relative statt absolute Pfade in der Konfiguration: Claude Desktop startet Serverprozesse nicht zwingend aus dem Projektordner heraus. Ein relativer Pfad wie python server.py in der Konfigurationsdatei schlägt dadurch oft fehl, während der absolute Pfad zuverlässig funktioniert.
Zu vage Tool-Beschreibungen: Ein Docstring wie “macht Wetter” liefert dem Modell zu wenig Kontext, um das Tool korrekt einzusetzen. Konkrete Parameterbeschreibungen und ein klarer Rückgabewert-Hinweis verbessern die Trefferquote spürbar.
Fehlendes Error-Handling in Tools: Wirft eine Funktion eine unbehandelte Ausnahme, kann das je nach Client zu einem stillen Abbruch statt zu einer verständlichen Fehlermeldung führen. Ein bewusstes try/except mit aussagekräftigem Rückgabetext ist deutlich robuster.
Geheimnisse direkt im Code: API-Schlüssel oder Auth-Token gehören in Umgebungsvariablen, nicht in die Serverdatei selbst, sonst landen sie schnell versehentlich in einem Git-Repository.
Veralteter SSE-Transport statt Streamable HTTP: Ältere Tutorials zeigen teils noch den mit Protokollversion 2024-11-05 verbundenen SSE-Transport. Für neue Projekte ist Streamable HTTP die aktuelle Empfehlung.
Zu breite Dateisystem- oder Netzwerkrechte: Ein Tool, das pauschal auf das gesamte Dateisystem zugreifen darf, öffnet unnötige Angriffsflächen. Rechte sollten so eng wie möglich zugeschnitten sein.
Kein Neustart nach Konfigurationsänderung: Claude Desktop liest die Konfigurationsdatei nur beim Start ein. Wer nach einer Änderung nur das Fenster schließt statt die App komplett zu beenden, sieht die Anpassung nicht.

Troubleshooting: Die häufigsten Fehler und ihre Lösungen

Problem	Wahrscheinliche Ursache	Lösung
Server erscheint nicht in Claude Desktop	Falscher oder relativer Pfad in `claude_desktop_config.json`	Absoluten Pfad zum Python-Interpreter und zur Serverdatei eintragen, App komplett neu starten
Fehler “spawn ENOENT”	Der angegebene Befehl liegt nicht im PATH der gestarteten App	Vollständigen Pfad zum Interpreter statt nur “python” verwenden
Inspector verbindet, zeigt aber keine Tools	Dekorator `@mcp.tool()` fehlt oder Funktion liegt außerhalb der Serverinstanz	Registrierung im Code prüfen, Server neu starten
JSON-Schema-Validierungsfehler beim Tool-Aufruf	Typannotationen der Python-Funktion passen nicht zu den übergebenen Werten	Parametertypen (float, int, str) exakt an die erwarteten Eingaben anpassen
Tool-Aufruf hängt oder läuft in Timeout	Synchroner, blockierender Code in einer async-Funktion	Asynchrone HTTP-Bibliothek wie httpx statt requests verwenden
“Permission denied” beim Dateizugriff	Server läuft mit eingeschränkten Rechten oder falschem Arbeitsverzeichnis	Arbeitsverzeichnis und Dateirechte für den startenden Nutzer prüfen
“Method not found” vom Client	Versionsmismatch zwischen SDK-Version des Servers und des Clients	SDK auf beiden Seiten auf die aktuelle Version anheben
HTTP 401 bei Remote-Server-Zugriff	Fehlendes oder falsches Bearer-Token im Anfrage-Header	Token in Client-Konfiguration und Serverumgebung abgleichen
Doppelte Server-Einträge nach Update	Alte Konfigurationszeilen wurden nicht entfernt	Konfigurationsdatei bereinigen, nur einen Eintrag pro Server behalten
Fehlerhafte Umlaute in der Ausgabe unter Windows	Falsche Konsolen-Codepage statt UTF-8	Terminal auf UTF-8 umstellen oder Ausgabe explizit kodieren

Fast alle diese Fälle lassen sich mit demselben Werkzeug eingrenzen: dem MCP Inspector aus Schritt 7. Wer bei einem Fehler zuerst den Server isoliert über den Inspector testet, statt sofort in Claude Desktop zu debuggen, trennt zuverlässig zwischen einem Problem im eigenen Servercode und einem Problem in der Client-Konfiguration.

Sicherheitsrisiken bei MCP-Servern

Mit dem schnellen Wachstum des Ökosystems wächst auch die Angriffsfläche. Sicherheitsanalysen zum Thema beschreiben MCP inzwischen als potenzielle Quelle neuer Sicherheitsschulden in Unternehmensumgebungen, insbesondere dort, wo Agenten Server von Drittanbietern mit weitreichenden Datei- oder Netzwerkrechten einbinden. Drei Angriffsmuster tauchen dabei besonders häufig in Fachdiskussionen auf.

Tool Poisoning bezeichnet manipulierte Tool-Beschreibungen, die für das menschliche Auge harmlos aussehen, dem Sprachmodell aber versteckte Anweisungen unterjubeln, etwa zusätzliche, nicht dokumentierte Aktionen. Da das Modell den Docstring als vertrauenswürdigen Kontext behandelt, kann eine präparierte Beschreibung Verhalten auslösen, das Entwickler nie beabsichtigt haben. Prompt Injection über Tool-Ausgaben funktioniert ähnlich, nur dass hier nicht die Beschreibung, sondern die Antwort eines Tools manipulierten Text enthält, den das Modell anschließend als Anweisung statt als reine Daten interpretiert. Wer sich tiefer mit Gegenmaßnahmen beschäftigen will, findet dazu ausführliche Praxisbeispiele in unserer Anleitung zu Prompt-Injection-Schutz bei LLMs.

Das dritte Muster, der sogenannte Confused-Deputy-Angriff, entsteht, wenn ein Server im Namen des Nutzers Aktionen ausführt, für die er eigentlich keine Berechtigung haben sollte, weil er die Rechte eines anderen, vertrauenswürdigeren Dienstes mitbenutzt. Gegen alle drei Muster hilft im Kern dasselbe Prinzip: Rechte so eng wie möglich zuschneiden, Server nur aus vertrauenswürdigen Quellen einbinden und Tool-Beschreibungen vor dem produktiven Einsatz manuell lesen, statt sie blind aus einem Repository zu übernehmen.

Für den produktiven Einsatz empfiehlt sich zusätzlich eine Allowlist statt einer Blocklist: Nur explizit freigegebene Server dürfen sich mit einem Client verbinden, alles andere wird standardmäßig abgelehnt. In größeren Teams sollte diese Freigabe zentral verwaltet werden, statt jeder einzelnen Entwicklerin oder jedem Entwickler zu überlassen, welchem Server sie oder er vertraut. Gerade weil ein Tool mit Dateisystemzugriff oder Zahlungsfunktionen im Zweifel mehr kann, als der Docstring verspricht, lohnt sich vor dem ersten produktiven Einsatz zusätzlich ein kurzer Blick in den Quellcode, nicht nur in die veröffentlichte Beschreibung.

Für Unternehmen in Deutschland und der übrigen DACH-Region kommt eine zusätzliche Ebene dazu: die DSGVO. Sobald ein Tool personenbezogene Daten liest oder zurückgibt, etwa Kundendaten aus einem CRM oder Mitarbeiterdaten aus einem HR-System, wird der MCP-Server faktisch Teil der Auftragsverarbeitung. Wer einen Server bei einem externen Anbieter hostet, statt ihn selbst zu betreiben, sollte deshalb vorab klären, wo die Daten tatsächlich verarbeitet werden und ob ein Auftragsverarbeitungsvertrag vorliegt. Ein lokal betriebener stdio-Server, der nie das eigene Netzwerk verlässt, umgeht diese Fragestellung von vornherein, ein öffentlich erreichbarer Streamable-HTTP-Server dagegen nicht.

Fortgeschrittene Tipps für Produktions-Setups

Wer über das erste Testprojekt hinausgeht, sollte strukturiertes Logging von Anfang an einplanen. Da stdio-Server die Standardausgabe für das Protokoll selbst nutzen, darf Logging niemals über print() laufen, sondern gehört ausschließlich in eine separate Logdatei oder auf die Standardfehlerausgabe, sonst zerstört ein einzelner Debug-Print die gesamte Kommunikation mit dem Client.

Für Teams, die mehrere Server parallel betreiben, lohnt sich außerdem eine zentrale Registry im eigenen Netzwerk, angelehnt an das Vorbild von registry.modelcontextprotocol.io. So lassen sich interne Server unter einem einheitlichen Reverse-DNS-Schema auffindbar machen, ohne dass jedes Team seine eigene Liste von Server-URLs pflegen muss. Wer zusätzlich mehrere Sprachmodell-Anbieter im selben Agenten einsetzt, profitiert davon, MCP-Server unabhängig vom jeweiligen Modell zu bauen und die Modellauswahl über eine RAG-Pipeline oder einen dedizierten Router zu steuern, statt Modelllogik im Server selbst zu verankern.

Ein letzter Tipp betrifft Tests: Der MCP Inspector eignet sich auch als CLI-Werkzeug für automatisierte Prüfungen in einer Continuous-Integration-Pipeline. Ein einfacher Smoke-Test, der beim Start des Servers alle registrierten Tools auflistet, fängt kaputte Deployments ab, bevor sie überhaupt bei echten Nutzerinnen und Nutzern ankommen.

Da sich sowohl das Python- als auch das TypeScript-SDK weiterhin regelmäßig aktualisieren, lohnt sich außerdem, Versionsnummern in einer requirements.txt beziehungsweise package.json fest einzufrieren, statt bei jedem Deployment ungeprüft die neueste Version zu ziehen. Ein SDK-Update kann Feldnamen oder Verhalten ändern, gerade weil sich die Spezifikation selbst 2026 noch in spürbarer Bewegung befindet. Wer zusätzlich denselben Server sowohl mit Claude Desktop als auch mit einem zweiten Client wie einem selbstgebauten Agenten testet, bevor eine neue Version produktiv geht, fängt Inkompatibilitäten ab, die sich in nur einem Client nie zeigen würden.

Für Remote-Server per Streamable HTTP zahlt sich zudem einfache Beobachtbarkeit aus: Wer jeden Tool-Aufruf mit Zeitstempel, aufrufendem Client und Antwortzeit protokolliert, findet bei Auffälligkeiten schneller heraus, ob ein einzelner Nutzer den Server überlastet oder ob ein bestimmtes Tool systematisch langsam antwortet. Für den Einstieg reicht dafür ein einfaches strukturiertes Log im JSON-Format, eine vollwertige Metrikenpipeline mit Dashboards ist erst ab einer gewissen Nutzerzahl wirklich nötig.

MCP im Überblick: Adoption und Registries im September 2026

Wie stark MCP inzwischen tatsächlich genutzt wird, lässt sich am besten an den öffentlich einsehbaren Registries ablesen. Die folgende Tabelle fasst die zuletzt verfügbaren Zahlen zusammen, jeweils mit Datum der Erhebung, da sich die Werte angesichts des Wachstumstempos von Monat zu Monat spürbar verschieben.

Quelle	Kennzahl	Stand
Offizielle MCP-Registry	über 22.000 aktive Server	19. August 2026
Offizielle MCP-Registry	rund 9.600 Servereinträge (früherer Schnappschuss)	Mai 2026
Repository modelcontextprotocol/servers	über 90.300 GitHub-Sterne	September 2026
Repository modelcontextprotocol/python-sdk	über 24.300 GitHub-Sterne	September 2026
Drittanbieter-Verzeichnisse (u. a. Smithery, mcp.so, Glama, PulseMCP)	zusammen mehrere Zehntausend zusätzliche Listings	August 2026

Auffällig ist vor allem das Tempo: Zwischen dem Mai- und dem August-Schnappschuss der offiziellen Registry hat sich die Zahl aktiver Server mehr als verdoppelt. Für Teams, die noch zögern, ob sich der Aufbau eines eigenen Servers lohnt, ist das ein starkes Indiz dafür, dass MCP kein kurzlebiger Trend, sondern inzwischen fester Bestandteil der Agenten-Infrastruktur ist.

FAQ: Häufig gestellte Fragen zu MCP-Servern

Ist MCP nur für Claude gedacht?
Nein. MCP ist ein offener Standard, den inzwischen auch ChatGPT, Gemini und Microsoft Copilot Studio unterstützen. Ein einmal gebauter Server lässt sich grundsätzlich an jeden Client anschließen, der das Protokoll implementiert, ein zusätzlicher Portierungsaufwand entfällt in aller Regel.

Brauche ich für einen MCP-Server zwingend Python oder TypeScript?
Nein, das sind lediglich die beiden offiziellen SDKs mit der größten Community. Die Spezifikation selbst ist sprachunabhängig, community-getragene SDKs existieren auch für andere Sprachen, allerdings mit deutlich kleinerer Nutzerbasis und entsprechend weniger Beispielen zum Nachschlagen.

Was kostet der Betrieb eines eigenen MCP-Servers?
Für einen lokalen stdio-Server über die eigene Laptop-CPU entstehen praktisch keine zusätzlichen Kosten. Ein remote per Streamable HTTP betriebener Server verursacht dieselben Hosting-Kosten wie jeder andere kleine Webdienst, meist im niedrigen einstelligen Euro-Bereich pro Monat bei einfachen Anwendungsfällen.

Wie unterscheidet sich MCP von einer klassischen REST-API?
Eine REST-API muss für jedes Sprachmodell einzeln integriert und dokumentiert werden, meist über eine separate, von Hand gepflegte Tool-Beschreibung im jeweiligen Anwendungscode. Ein MCP-Server bringt diese Beschreibung direkt mit und ist für beliebige MCP-fähige Clients ohne Zusatzaufwand nutzbar, die REST-API kann dabei weiterhin im Hintergrund als eigentliche Datenquelle dienen.

Kann ich vorhandene MCP-Server aus der Community einfach übernehmen?
Technisch ja, sicherheitstechnisch nur mit Vorsicht. Da Server im Namen des Nutzers Aktionen ausführen können, sollten Quellcode und Tool-Beschreibungen vor dem Einsatz geprüft werden, insbesondere bei Servern mit Datei- oder Zahlungszugriff.

Was ist der Unterschied zwischen stdio und Streamable HTTP?
Stdio eignet sich für lokal auf demselben Rechner laufende Server und ist am einfachsten einzurichten. Streamable HTTP erlaubt den Betrieb als Netzwerkdienst und ersetzt den älteren, inzwischen abgelösten HTTP-plus-SSE-Transport vollständig.

Wie teste ich, ob mein Server sicher konfiguriert ist?
Ein guter erster Schritt ist eine Prüfung der vergebenen Datei- und Netzwerkrechte sowie ein manueller Blick in jede Tool-Beschreibung. Ergänzend hilft der MCP Inspector dabei, das tatsächliche Verhalten aller Tools vor dem produktiven Einsatz nachzuvollziehen.

Lohnt sich MCP für kleine Projekte oder nur für große Unternehmen?
Auch einzelne Entwicklerinnen und Entwickler profitieren, etwa um einen persönlichen Assistenten an private Notizen oder Kalender anzubinden. Der Aufwand für einen einfachen Server mit ein bis zwei Tools liegt bei wenigen Stunden.

Muss ein MCP-Server im Internet erreichbar sein, um nützlich zu sein?
Nein. Die meisten Server laufen zu Beginn ausschließlich lokal über stdio und werden nie öffentlich erreichbar gemacht. Erst wenn mehrere Personen oder mehrere Geräte denselben Server nutzen sollen, wird ein per Streamable HTTP erreichbarer Remote-Server sinnvoll, inklusive der in Schritt 11 gezeigten Zugriffskontrolle.

Weiterführende technische Dokumentation: die offizielle MCP-Einführung, die MCP-Spezifikation, das Repository mit Referenzservern auf GitHub, die offizielle Quickstart-Anleitung sowie die ursprüngliche Ankündigung von Anthropic.

MCP-Server einrichten: 12 Schritte, 90.363 Stars [2026]