MCP-Server auf einem VPS für KI-Coding-Agenten betreiben

Was Sie aufbauen

Zwei funktionierende MCP-Setups auf einem VPS. Zuerst einen stdio-Server, also ein Datei- oder Datenbank-Tool, das Claude Code als untergeordneten Prozess startet und über eine Pipe mit ihm kommuniziert. Anschließend einen remote HTTP-Server, der als dauerhaft laufender Netzwerkdienst hinter systemd und einem Nginx-Reverse-Proxy mit TLS ausgeführt wird. Er ist für jeden MCP-Client erreichbar, den Sie darauf konfigurieren. Die Installation ist in beiden Fällen kurz. Der größte Teil dieses Leitfadens behandelt die zwei Punkte, die in der Praxis Probleme verursachen: Der JSON-RPC-Datenstrom muss sauber bleiben, und ein nicht authentifizierter Tool-Endpunkt darf niemals öffentlich im Internet erreichbar sein.

Was MCP tatsächlich ist

Das Model Context Protocol ist ein Standard, über den ein KI-Client wie Claude Code, Claude Desktop, die Gemini CLI auf einem VPS oder Ihr eigenes Skript externe Tools aufrufen und externe Ressourcen lesen kann. Das Modell selbst führt nichts aus. Es stellt eine Anfrage an den Client. Der Client spricht über JSON-RPC 2.0 mit einem MCP-Server. Der Server führt das Tool aus und gibt das Ergebnis zurück. Dieser Client ist mit dem Begriff Agent-Harness gemeint: die Schleife um das Modell, die die Tool-Liste, die Berechtigungsprüfungen und den Sitzungsstatus verwaltet. MCP erweitert dabei lediglich den Tool-Teil. Ein Protokoll genügt. Ein von Ihnen einmal geschriebener Server funktioniert dadurch mit jedem Client, der MCP unterstützt. Wenn diese Trennung für Sie neu ist und Sie insbesondere wissen möchten, wie ein Modell überhaupt entscheidet, ein Tool aufzurufen, lohnt sich ein schrittweiser Einstieg in die Grundlagen von Agenten eine Stunde, bevor Sie einem dieser Server echte Zugangsdaten geben.

Es gibt zwei Transportarten. Der restliche Teil dieses Leitfadens ist entsprechend aufgeteilt:

• stdio. Der Client startet den Server als untergeordneten Prozess und tauscht zeilengetrennte JSON-RPC-Nachrichten über dessen Standardeingabe und Standardausgabe aus. Es gibt kein Netzwerk, keinen Port und keine Authentifizierung. Die Vertrauensgrenze ist der Prozess selbst. Fast jedes lokale Tool wird auf diese Weise ausgeliefert.
• Streamable HTTP (und der ältere Verwandte HTTP+SSE). Der Server ist ein dauerhaft laufender Webdienst. Der Client verbindet sich über HTTP. Der Server kann Antworten als Server-Sent Events zurückstreamen. So können Sie einen Server mit mehreren Clients gemeinsam verwenden oder ein Tool betreiben, das dauerhaft auf dem System laufen muss.

Verwenden Sie stdio, wenn das Tool zu einem einzelnen System und einem einzelnen Benutzer gehört. Verwenden Sie HTTP, wenn es sich um einen gemeinsam genutzten Dienst handelt.

Voraussetzungen und die tatsächlichen Stolpersteine

Gehen Sie von einem frischen Ubuntu-24.04-KVM-VPS mit root- oder sudo-Zugriff aus. Darüber hinaus benötigen Sie:

• Eine Laufzeitumgebung, in der der Server geschrieben ist. Die meisten Referenzserver verwenden Node oder Python. Ubuntu 24.04 enthält Node 18, mehrere aktuelle MCP-Pakete erfordern jedoch Node 20 oder neuer. Installieren Sie daher eine aktuelle LTS-Version über NodeSource oder nvm, statt apt zu vertrauen. Python 3.12 ist bereits vorhanden.
• Eine Domain und einen DNS-A-Record, aber nur für den Remote-HTTP-Server. Für TLS muss ein Name auf diesen VPS aufgelöst werden. Das stdio-Beispiel benötigt überhaupt kein DNS.
• 512 MB RAM reichen aus. MCP-Server sind schlanke JSON-RPC-Prozesse. Der Speicherbedarf entsteht durch das, worauf Ihr Tool zugreift, beispielsweise durch einen Datenbanktreiber oder einen Dateicache, nicht durch das Protokoll.
• Die Spezifikation ist noch jung und wird weiterentwickelt. Die Revision vom 2025-03-26 ersetzte HTTP+SSE durch Streamable HTTP und kennzeichnete SSE als veraltet. SSE funktioniert weiterhin, und viele Server unterstützen es nach wie vor. Betrachten Sie daher jede festgelegte Transportart als etwas, das Sie anhand der Release Notes des Servers erneut prüfen müssen, nicht als unveränderliche Vorgabe.

Schritt 1: Einen stdio-Server in Claude Code einbinden

Beginnen Sie mit dem Filesystem-Server. Er ist offiziell, wird aktiv gepflegt und benötigt nur Node. Der folgende Befehl registriert ihn bei Claude Code und begrenzt ihn auf das aktuelle Projekt, sodass die Konfiguration in einer commitbaren Datei gespeichert wird:

cd /home/matt/projects/api
claude mcp add --scope project --transport stdio filesystem \
  -- npx -y @modelcontextprotocol/server-filesystem /home/matt/projects/api

Das Trennzeichen -- ist wichtig: Alles danach ist der Befehl, den Claude Code ausführt, und kein Flag für Claude Code. Dadurch wird eine .mcp.json im Projektstamm angelegt:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/matt/projects/api"
      ]
    }
  }
}

Es läuft noch nichts. Wenn Sie Claude Code das nächste Mal in diesem Verzeichnis starten, liest der Agent .mcp.json ein, startet npx -y @modelcontextprotocol/server-filesystem ... als Kindprozess und führt den MCP-Handshake über stdin/stdout dieses Prozesses aus. Prüfen Sie, ob die Einrichtung funktioniert hat:

claude mcp list

Ein funktionierender Server gibt seinen Befehl und ein grünes Häkchen aus: filesystem: npx -y @modelcontextprotocol/server-filesystem ... - ✓ Connected. Innerhalb der Sitzung listet der Slash-Befehl /mcp die Tools auf, die der Server bereitstellt (read_file, write_file, list_directory). Der Agent kann sie jetzt für die freigegebenen Pfade aufrufen. Ein Datenbanktool wird auf dieselbe Weise eingerichtet. Tauschen Sie das Paket aus und übergeben Sie eine Verbindungszeichenfolge als letztes Argument. Prüfen Sie jedoch im Repository des Servers den aktuellen Paketnamen, da der Referenzserver für Postgres mehrfach den Besitzer gewechselt hat.

Das ist der eigentliche Zweck, den Agenten auf dem Server auszuführen: Die Claude-Code-Sitzung läuft auf dem VPS innerhalb von tmux, und die stdio-Server laufen direkt daneben. Sie haben direkten Zugriff auf die Projektdateien und lokalen Dienste, ohne Netzwerk-Roundtrip. Sobald der Agent sowohl write_file als auch read_file besitzt, sollten Sie diese Reichweite mit einem Skill kombinieren, der ihn zu möglichst kleinen funktionierenden Änderungen anhält, weil ein Filesystem-Tool eine weitreichende Neufassung genauso einfach macht wie eine Korrektur in zwei Zeilen. Dieselbe Einbindung geht über lokale Dateien hinaus: Wenn Sie auf dem VPS bereits eine Suchmaschine betreiben, können Sie dem Agenten Ihre eigene SearXNG-Instanz als Suchtool übergeben. Dadurch bleiben die Suchanfragen auf Ihrem Server, während nicht vertrauenswürdiger Seitentext direkt in den Kontext gelangt, auf dessen Grundlage der Agent anschließend handelt.

Schritt 2: Einen entfernten HTTP-Server erstellen

Ein stdio-Server wird zusammen mit seinem übergeordneten Prozess beendet und für jeden Client einmal gestartet. Wenn Sie also zwei Claude-Code-Sitzungen auf dem Server ausführen, die Arbeit aneinander übergeben, erhält jede Sitzung eine eigene private Kopie des Tools. Wenn ein Tool für alle Clients dauerhaft verfügbar sein soll, etwa ein gemeinsames Operations-Tool oder ein Datenbank-Gateway, das sowohl Ihr Laptop als auch Ihre CI aufrufen, benötigen Sie den HTTP-Transport und einen echten Dienst. Hier ist ein minimaler Python-Server mit dem offiziellen SDK, der ein Tool bereitstellt:

# /opt/mcp-ops/server.py
from mcp.server.fastmcp import FastMCP
import subprocess

mcp = FastMCP("ops-tools", host="127.0.0.1", port=8000)

@mcp.tool()
def disk_free() -> str:
    """Return `df -h` for the server."""
    out = subprocess.run(["df", "-h"], capture_output=True, text=True)
    return out.stdout

if __name__ == "__main__":
    # Serves Streamable HTTP at /mcp on 127.0.0.1:8000
    mcp.run(transport="streamable-http")

Beachten Sie host="127.0.0.1". Der Server bindet nur an localhost. Nichts außerhalb des Servers kann ihn direkt erreichen. Das ist genau das gewünschte Verhalten, solange noch keine Authentifizierung vorhanden ist. Installieren Sie ihn in einer eigenen virtuellen Umgebung, damit systemd einen stabilen Interpreter-Pfad verwendet:

sudo useradd --system --home /opt/mcp-ops --shell /usr/sbin/nologin mcp
sudo install -d -o mcp -g mcp /opt/mcp-ops
sudo -H -u mcp python3 -m venv /opt/mcp-ops/.venv
sudo -H -u mcp /opt/mcp-ops/.venv/bin/pip install "mcp[cli]"

Schritt 3: Mit systemd dauerhaft ausführen

Ein Tool, das nicht verfügbar ist, wenn der Agent es aufruft, ist schlechter als gar kein Tool. Das ist besonders wichtig, wenn der Client selbst ein langlebiger Prozess ist: Ein dauerhaft laufender Agent, der seinen Speicher und seine Zeitpläne über Reboots hinweg beibehält ruft diese Tools nach einem Zeitplan auf, ohne dass jemand den Vorgang überwacht. Deshalb muss der Server ebenfalls selbstständig wieder starten. Schreiben Sie /etc/systemd/system/mcp-ops.service:

[Unit]
Description=MCP ops-tools server
After=network.target

[Service]
Type=simple
User=mcp
WorkingDirectory=/opt/mcp-ops
ExecStart=/opt/mcp-ops/.venv/bin/python /opt/mcp-ops/server.py
Restart=on-failure
RestartSec=2
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true

[Install]
WantedBy=multi-user.target

Der absolute Pfad zum venv-Python in ExecStart ist erforderlich. Zeigen Sie ihn auf /usr/bin/python3, und starten Sie den Prozess mit ModuleNotFoundError: No module named 'mcp', weil der Systeminterpreter Ihr pip install nicht kennt. Aktivieren und prüfen Sie den Dienst:

sudo systemctl daemon-reload
sudo systemctl enable --now mcp-ops
sudo systemctl status mcp-ops
curl -si -H 'Accept: application/json, text/event-stream' \
  -H 'Content-Type: application/json' \
  -X POST http://127.0.0.1:8000/mcp

status sollte active (running) anzeigen. curl gibt HTTP/1.1 400 Bad Request mit einem JSON-RPC-Fehler im Antworttext zurück. Die Anfrage enthielt keine Sitzung und keine gültigen JSON-Nutzdaten. Genau das ist hier erwünscht: Es beweist, dass der Port antwortet und das Protokoll spricht. Connection refused oder eine leere Antwort bedeutet, dass der Prozess nicht an die erwartete Adresse gebunden ist. Lesen Sie journalctl -u mcp-ops -n 50.

Schritt 4: TLS und einen Reverse Proxy vorschalten

Der Server lauscht auf localhost. Damit Sie ihn von überall erreichen, terminieren Sie TLS in nginx und leiten die Anfragen intern per Proxy weiter. Installieren Sie nginx, beziehen Sie ein Zertifikat mit Certbot und Let’s Encrypt mit nginx und schreiben Sie anschließend den location-Block. Entscheidend ist, das Buffering zu deaktivieren. Das Standardverhalten von nginx hält eine Antwort zurück, bis sie vollständig ist. Dadurch bleibt ein SSE-Stream dauerhaft hängen:

server {
    listen 443 ssl;
    server_name mcp.example.com;

    # ssl_certificate lines managed by Certbot

    location /mcp {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;

        # The four lines that make SSE work through nginx:
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        chunked_transfer_encoding off;
    }
}

Laden Sie die Konfiguration mit sudo nginx -t && sudo systemctl reload nginx neu. Wenn Sie bereits eine größere Anzahl von Containern betreiben, übernimmt ein Traefik-Reverse-Proxy mit automatischem TLS dieselbe Aufgabe. Er stellt das Zertifikat aus und leitet Anfragen anhand des Hostnamens weiter. Sie müssen dann nur Labels zum MCP-Container hinzufügen. In beiden Fällen ist der Reverse Proxy jetzt das einzige System an einem öffentlichen Port. Er leitet auf einen Dienst weiter, den Sie noch nicht abgesichert haben. Beheben Sie das, bevor Sie die URL irgendwo registrieren.

Schritt 5: Die Sicherheitsregel, die dieses Thema bestimmt

Niemals einen nicht authentifizierten MCP-Endpunkt öffentlich bereitstellen. Ein MCP-Server ist keine schreibgeschützte API. Er gewährt Zugriff auf Tools, Ihre Dateien, Ihre Datenbank und manchmal auf eine Shell. Ein offener /mcp im öffentlichen Internet ist ein Fremder mit demselben Zugriff wie Ihr AI-Agent: Er listet Ihre Tools auf und ruft sie anschließend auf. Behandeln Sie ihn genau wie einen nicht authentifizierten Admin-Socket, denn genau das ist er. Wie viel ein gestohlenes Token ermöglicht, hängt auch vom dahinterliegenden Server ab: der schreibgeschützte MCP-Server, der mit dem openGym-Workout-Tracker ausgeliefert wird kann ausschließlich Trainingsdaten zurückgeben, während ein Datei- oder Shell-Tool den Zugriff auf das System ermöglicht.

Drei Schutzmaßnahmen, nach Priorität geordnet:

1. Veröffentlichen Sie ihn nicht. Lassen Sie den Server auf 127.0.0.1 laufen und greifen Sie von Ihrem Laptop über einen SSH-Tunnel darauf zu: ssh -L 8000:127.0.0.1:8000 matt@vps. Richten Sie den Client anschließend auf http://127.0.0.1:8000/mcp. Dadurch wird nichts öffentlich erreichbar.
2. Betreiben Sie ihn in einem privaten Netzwerk. Binden Sie die Tunnel-Adresse eines selbst gehosteten WireGuard-VPNs und erlauben Sie nur VPN-Peers den Zugriff. Im öffentlichen Internet bleibt der Port geschlossen.
3. Wenn der Endpunkt öffentlich erreichbar sein muss, verlangen Sie ein Token. Die korrekte Lösung ist der MCP-OAuth-Flow, den der HTTP-Transport nativ unterstützt. Die pragmatische Mindestlösung ist ein gemeinsames Bearer-Token, das am Proxy geprüft wird. Das ist einfach umzusetzen und verhindert beliebige Zugriffsversuche vollständig:

location /mcp {
    if ($http_authorization != "Bearer REPLACE_WITH_LONG_RANDOM") {
        return 401;
    }
    proxy_pass http://127.0.0.1:8000;
    # ...buffering-off block from above...
}

Generieren Sie das Token mit openssl rand -hex 32. Binden Sie den Server selbst niemals ohne eine dieser Schutzmaßnahmen davor an 0.0.0.0. Der Client sendet das Token anschließend als Header. In Claude Code:

claude mcp add --scope project --transport http ops-tools https://mcp.example.com/mcp \
  --header 'Authorization: Bearer ${MCP_TOKEN}'

Setzen Sie MCP_TOKEN in Ihrer Shell, damit das Secret nicht im Klartext in .mcp.json landet. Claude Code erweitert ${MCP_TOKEN} beim Lesen aus der Umgebung.

Alle oben genannten Schutzmaßnahmen sichern den Endpunkt und nicht den Agenten, der das Token bereits besitzt. Das ist die andere Hälfte des Problems: Wenn Ihr Client der DeepSeek Harness ist, decken Plugins, die steuern, welche Tools ein Agent aufrufen darf, und die Toolausgabe auf eingeschleuste Anweisungen prüfen diese Seite ab.

Schritt 6: Mit dem MCP Inspector debuggen

Wenn sich ein Server fehlerhaft verhält, sollten Sie nicht innerhalb des Agents spekulieren. Steuern Sie ihn stattdessen direkt mit dem Inspector, dem offiziellen webbasierten Testclient. Für einen stdio-Server übergeben Sie ihm denselben Befehl, den der Agent ausführt:

npx @modelcontextprotocol/inspector \
  npx -y @modelcontextprotocol/server-filesystem /tmp

Der Inspector startet eine Benutzeroberfläche auf http://localhost:6274. Neuere Versionen geben eine URL mit einer MCP_PROXY_AUTH_TOKEN-Abfragezeichenfolge aus. Verwenden Sie genau diesen Link, andernfalls weist die Benutzeroberfläche die Verbindung zurück. Zusätzlich startet er einen Proxy auf Port 6277. Klicken Sie auf Connect, anschließend auf List Tools und dann auf Call Tool. Verwenden Sie dabei echte Argumente. Funktioniert der Server im Inspector, schlägt aber im Agent fehl, liegt der Fehler in Ihrer Client-Konfiguration und nicht im Server. Wählen Sie für den entfernten HTTP-Server den Transport Streamable HTTP, geben Sie https://mcp.example.com/mcp ein, fügen Sie den Header Authorization hinzu und stellen Sie die Verbindung her. So lässt sich am schnellsten nachweisen, dass Authentifizierung und Proxy korrekt funktionieren, bevor ein Agent beteiligt ist.

Server aktualisieren

MCP entwickelt sich schnell weiter. Installieren Sie Aktualisierungen daher nach einem festen Zeitplan. Node-Server, die mit npx -y gestartet werden, rufen bei jedem Start die aktuelle Version ab. Das ist praktisch, aber nicht reproduzierbar. Sobald ein Server relevant ist, pinnen Sie die exakt getestete Version. Lesen Sie sie aus npm view @modelcontextprotocol/server-filesystem version aus und hängen Sie sie in .mcp.json an den Paketnamen an (@modelcontextprotocol/server-filesystem@<version>). Aktualisieren Sie die Version anschließend bewusst. Python-Server unter systemd aktualisieren Sie mit sudo -H -u mcp /opt/mcp-ops/.venv/bin/pip install -U "mcp[cli]", gefolgt von sudo systemctl restart mcp-ops. Prüfen Sie beim Upgrade die Spezifikationsrevision, auf die Ihr SDK abzielt. Ein Wechsel über die Grenze von SSE zu Streamable HTTP kann das Transportprotokoll ändern, das Ihre Clients anfordern müssen.

Fehlerbilder und die dabei angezeigten Meldungen

Der Agent meldet, dass der Server fehlgeschlagen ist. claude mcp list gibt ✗ Failed to connect aus, und die TUI meldet MCP server 'filesystem' failed to start. Führen Sie claude --debug aus. In der Ausgabe sehen Sie normalerweise Error: spawn npx ENOENT. Der Befehl befindet sich nicht im claude mcp list des Agents. Die Laufzeitumgebung fehlt oder befindet sich nicht an dem Pfad, den der Agent durchsucht: Node ist nicht installiert, npx fehlt oder ein virtualenv-Python wird über seinen bloßen Namen referenziert. Korrigieren Sie den Befehl auf einen absoluten Pfad oder installieren Sie die Laufzeitumgebung. Stellen Sie anschließend die Verbindung erneut her.

Ein stdio-Server verbindet sich und wird dann sofort getrennt. Der Client protokolliert einen JSON-Parsefehler, etwa Unexpected token 'S', "Server sta"... is not valid JSON oder Failed to parse message. Die Ursache ist immer gleich: Der Server hat eine Protokollzeile nach stdout geschrieben. Bei stdio ist stdout der JSON-RPC-Kanal. Jeder zusätzliche Text beschädigt daher den Datenstrom, und der Handshake schlägt fehl. In Node wird console.log nach stdout geschrieben. Verwenden Sie console.error. In Python wird ein unformatiertes print() nach stdout geschrieben. Schreiben Sie Logs mit logging, das auf sys.stderr konfiguriert ist, oder übergeben Sie file=sys.stderr. Die Regel ist eindeutig: Bei stdio darf stdout ausschließlich JSON-RPC enthalten. Alle für Menschen bestimmten Ausgaben gehören nach stderr.

Ein Remote-Server läuft beim Handshake in einen Timeout oder beendet die Verbindung. Der Client schlägt mit MCP error -32000: Connection closed fehl, oder der Inspector bleibt bei Connect hängen und listet keine Tools auf. Hinter nginx ist die Ursache das Buffering: Der Proxy hält den SSE-Datenstrom zurück, statt ihn sofort weiterzuleiten. Der Client wartet dadurch auf eine Antwort, die nie eintrifft. Fügen Sie proxy_buffering off; und den restlichen Block aus Schritt 4 in location ein. Prüfen Sie dies mit curl -N gegen die öffentliche URL. Die Eventdaten sollten schrittweise eintreffen, nicht erst am Ende gesammelt.

Die Authentifizierung wird abgelehnt. Der Client meldet Error POSTing to endpoint (HTTP 401) oder einfach 401 Unauthorized. Entweder fehlt der Header, das Token ist falsch oder die Shell-Variable war leer, als der Client die Konfiguration eingelesen hat. Das ist ein häufiger Fehler, weil ${MCP_TOKEN} zu nichts expandiert, wenn die Variable nicht gesetzt ist. nginx sieht dann Bearer ohne Wert. Geben Sie die Variable aus, fügen Sie den Header erneut hinzu und prüfen Sie, ob die exakten Bytes mit dem Token in if von nginx übereinstimmen.

Der Dienst startet unter systemd nicht. journalctl -u mcp-ops zeigt ModuleNotFoundError: No module named 'mcp' an. ExecStart verweist auf das System-Python statt auf den Interpreter des venv. Oder Address already in use: Ein anderer Prozess verwendet bereits Port 8000. Ermitteln Sie ihn mit sudo ss -ltnp | grep 8000.

FAQ

Was ist ein MCP-Server genau?

Ein MCP-Server ist ein Programm, das einem KI-Client über das Model Context Protocol Tools und Ressourcen bereitstellt und dafür JSON-RPC 2.0 verwendet. Das KI-Modell führt das Tool nie selbst aus. Es fordert seinen Client dazu auf, der Client ruft den MCP-Server auf, und der Server führt den Vorgang aus und gibt ein Ergebnis zurück. Da das Protokoll standardisiert ist, funktioniert ein Server mit jedem kompatiblen Client, unabhängig davon, ob es sich um Claude Code, Claude Desktop oder die Gemini CLI handelt.

Was ist der Unterschied zwischen stdio- und HTTP-Transport?

Ein stdio-Server wird vom Client als untergeordneter Prozess gestartet und kommuniziert über stdin/stdout. Er ist daher an einen Client auf einem Rechner gebunden und wird zusammen mit diesem beendet. Netzwerkzugriff und Authentifizierung sind nicht erforderlich. Ein HTTP-Server ist ein dauerhaft laufender Netzwerkdienst, den mehrere Clients gleichzeitig erreichen können. Deshalb benötigt er TLS und Authentifizierung. Verwenden Sie stdio für lokale Tools für einen einzelnen Benutzer. Verwenden Sie HTTP (bei aktuellen Servern Streamable HTTP) für gemeinsam genutzte oder dauerhaft laufende Dienste.

Wie sichere ich einen entfernten MCP-Server?

Gehen Sie davon aus, dass der Server Zugriff auf Ihre Dateien, Datenbank oder Shell gewährt. Machen Sie ihn niemals ohne Authentifizierung erreichbar. Am sichersten ist es, den Server an localhost zu binden und ihn über einen SSH-Tunnel oder ein privates VPN zu erreichen. Wenn er öffentlich erreichbar sein muss, schalten Sie einen Reverse Proxy davor, der ein Bearer-Token oder den MCP-OAuth-Flow erzwingt. Generieren Sie das Token mit openssl rand -hex 32. Binden Sie den Server niemals ohne eine dieser Schutzmaßnahmen davor an 0.0.0.0.

Wie debugge ich einen Server, der nicht startet?

Prüfen Sie zuerst claude mcp list. ✗ Failed to connect mit spawn ... ENOENT bedeutet, dass der Befehl oder die Laufzeitumgebung fehlt. Korrigieren Sie den Pfad oder installieren Sie die fehlende Komponente. Wenn die Verbindung zunächst hergestellt wird und dann mit einem JSON-Parse-Fehler abbricht, schreibt der Server Logs nach stdout und beschädigt dadurch den JSON-RPC-Datenstrom. Leiten Sie alle Logs nach stderr um. Für alle anderen Fälle führen Sie den exakten Befehl im MCP Inspector aus. Dieser steuert den Server isoliert, sodass Sie einen Serverfehler von einem Fehler in der Client-Konfiguration unterscheiden können.