Ein Claude-Chat, der Ihre lokalen Dateien liest. Ein Cursor-Projekt, das direkt gegen Ihre Postgres-Datenbank abfragt. Ein GitHub Copilot, der ein Ticket in Ihrem Tracker anlegt, ohne dass Sie den Editor verlassen. All das läuft über dasselbe Protokoll: das Model Context Protocol, kurz MCP. Anthropic hat MCP im November 2024 als offenen Standard veröffentlicht, und seitdem hat sich einiges getan. Die aktuelle Spezifikation trägt die Versionsnummer 2026-07-28 und markiert laut dem offiziellen MCP-Blog die “größte Überarbeitung seit dem Start” des Protokolls.

Diese Anleitung zeigt Ihnen, wie Sie MCP-Server in 13 Schritten aufsetzen und mit den gängigen KI-Coding-Tools verbinden: Claude Desktop, Claude Code, Cursor, VS Code mit GitHub Copilot und JetBrains-IDEs. Sie bekommen fertige Konfigurationsdateien, einen eigenen MCP-Server aus Node.js-Code und eine Liste der Fehler, die in der Praxis am häufigsten auftreten. Rechnen Sie mit etwa 40 Minuten für das Basis-Setup, mehr wenn Sie auch den eigenen Server am Ende bauen wollen.

Wie schnell sich MCP durchgesetzt hat, zeigt sich daran, dass kaum ein größerer Editor-Anbieter das Protokoll noch ignoriert. GitHub hat sein Copilot-Agent-Plugin-Ökosystem, über das shattered.io bereits berichtet hat, ausdrücklich auf MCP als gemeinsamen Standard aufgebaut. Für Entwickler in Österreich und Deutschland heißt das konkret: Eine einmal geschriebene Server-Integration für ein internes Tool lässt sich ohne Anpassung in mehreren Editoren gleichzeitig nutzen, egal ob im Team unterschiedliche IDEs im Einsatz sind.

Was ist MCP und warum lohnt sich das Setup?

MCP löst ein Problem, das jeder kennt, der KI-Assistenten in echten Workflows nutzt: Jedes Tool brauchte bisher seine eigene, proprietäre Integration, um an externe Daten heranzukommen. Ein Anbieter musste für Slack, GitHub, Postgres und das lokale Dateisystem jeweils eigenen Klebecode schreiben. MCP definiert stattdessen eine gemeinsame Schnittstelle: Ein MCP-Server stellt Werkzeuge, Ressourcen und Prompts bereit, ein MCP-Client (also Ihr Editor oder Ihr Chat-Fenster) spricht dieselbe Sprache mit jedem Server, unabhängig vom Hersteller.

Das Protokoll wird von Anthropic geleitet und im öffentlichen Repository modelcontextprotocol/modelcontextprotocol gepflegt. Die Spezifikation selbst ist als TypeScript-Schema definiert, offen einsehbar und wird aktiv weiterentwickelt, wie die Commit-Historie im Repository zeigt. Anthropic beschreibt MCP dabei ausdrücklich als herstellerneutrale Schicht, nicht als Claude-exklusives Feature. Genau deshalb unterstützen inzwischen auch Cursor, VS Code, JetBrains-IDEs und weitere Editoren das Protokoll nativ.

Der größte technische Umbruch kam mit der Spezifikation vom 28. Juli 2026. Sie macht den Protokollkern zustandslos und entfernt sowohl die serverseitigen Sitzungen als auch den bisherigen initialize-Handshake. Stattdessen handeln Client und Server die Protokollversion pro Anfrage aus. Für Sie als Anwender bedeutet das vor allem eines: Wenn Sie älteren Anleitungen aus 2025 folgen, kann es sein, dass Konfigurationsfelder oder Serverversionen nicht mehr zur aktuellen Spezifikation passen. Diese Anleitung ist auf dem Stand von September 2026 und berücksichtigt die neue, zustandslose Architektur.

Host, Client und Server: Die drei Rollen im Protokoll

MCP unterscheidet drei Rollen, und diese Begriffe tauchen in jeder Dokumentation wieder auf, deshalb lohnt sich eine kurze Klärung. Der Host ist die Anwendung, die Sie tatsächlich bedienen, also Claude Desktop, Cursor oder VS Code. Innerhalb des Hosts läuft ein oder mehrere MCP-Clients, jeweils für eine Verbindung zu genau einem Server zuständig. Der Server schließlich ist der externe Prozess, der Werkzeuge, Daten oder Vorlagen bereitstellt, in unseren Beispielen also etwa der Filesystem- oder der GitHub-Server. Diese Trennung erlaubt es einem Host, gleichzeitig mit einem Dutzend Servern zu sprechen, ohne dass die Server voneinander wissen oder sich gegenseitig beeinflussen können.

Werkzeuge, Ressourcen und Prompts: Die drei Bausteine eines Servers

Ein MCP-Server kann drei Arten von Fähigkeiten anbieten. Werkzeuge (Tools) sind Funktionen, die das Sprachmodell aktiv aufrufen kann, etwa “Datei lesen” oder “Issue erstellen”. Ressourcen (Resources) sind eher passive Datenquellen, die der Host bei Bedarf einlesen kann, zum Beispiel der Inhalt eines Logfiles oder eine Konfigurationsdatei. Prompts schließlich sind vorformulierte Vorlagen, die ein Server anbietet, damit Nutzer wiederkehrende Aufgaben mit einem Klick statt mit langen Texteingaben starten können. Der eigene Server, den Sie später in dieser Anleitung bauen, nutzt bewusst nur ein einziges Werkzeug, weil das für den Einstieg am leichtesten nachzuvollziehen ist. In echten Projekten kombinieren Server häufig mehrere Werkzeuge und Ressourcen in einem einzigen Prozess.

Voraussetzungen: Diese Versionen brauchen Sie

Bevor Sie loslegen, prüfen Sie, ob folgende Werkzeuge installiert sind. MCP-Server werden in den meisten Fällen über Node.js oder Python gestartet, daher brauchen Sie mindestens eine der beiden Laufzeitumgebungen.

  • Node.js 18 oder neuer (empfohlen: die aktuelle LTS-Version), inklusive npm und npx
  • Optional: Python 3.10 oder neuer, falls Sie Python-basierte MCP-Server nutzen wollen
  • Claude Desktop (aktuelle Version aus dem offiziellen Installer oder dem Microsoft Store) für die Chat-Integration
  • Claude Code (die CLI-Version von Anthropic) für die Terminal-Integration
  • Cursor, VS Code mit installierter GitHub-Copilot-Erweiterung, oder eine JetBrains-IDE wie IntelliJ IDEA oder PyCharm der Version 2026.2 oder neuer
  • Ein Texteditor für JSON-Dateien (ein einfacher Editor reicht, es muss kein spezielles Tool sein)
  • Für den GitHub-MCP-Server: ein GitHub Personal Access Token mit den passenden Berechtigungen

Ein wichtiger Hinweis vorweg: MCP-Server laufen standardmäßig mit denselben Rechten wie der Benutzer, der sie startet. Ein Dateisystem-Server kann also potenziell auf alles zugreifen, was Ihr Nutzerkonto lesen darf, wenn Sie die Pfade nicht einschränken. Dazu kommen wir ausführlich im Abschnitt zu Sicherheit und Berechtigungen. Wenn Sie in einem Firmenumfeld arbeiten, klären Sie außerdem vorab kurz mit Ihrer IT-Abteilung ab, ob das Ausführen von npx-Paketen und der Zugriff auf interne Systeme über MCP-Server mit den geltenden Richtlinien vereinbar ist, bevor Sie produktive Zugangsdaten in eine Konfiguration eintragen.

Schritt 1: Node.js und npx testen

Öffnen Sie ein Terminal und prüfen Sie, ob Node.js korrekt installiert ist. Die meisten offiziellen MCP-Server werden über npx gestartet, ein Tool, das Pakete herunterlädt und sofort ausführt, ohne dass Sie sie dauerhaft installieren müssen.

node -v
npm -v
npx --version

Wenn einer der Befehle einen Fehler wie “command not found” ausgibt, installieren Sie Node.js über den offiziellen Installer für Ihr Betriebssystem oder einen Versionsmanager wie nvm. Für dieses Tutorial reicht jede Node-Version ab 18 aufwärts. Sobald die drei Befehle Versionsnummern zurückgeben, sind Sie startklar für den ersten MCP-Server.

Schritt 2: Die Konfigurationsdatei von Claude Desktop finden

Claude Desktop liest seine MCP-Server aus einer einzigen JSON-Datei namens claude_desktop_config.json. Der Speicherort unterscheidet sich je nach Betriebssystem und teilweise sogar je nach Installationsart.

Betriebssystem / InstallationPfad zur Konfigurationsdatei
macOS~/Library/Application Support/Claude/claude_desktop_config.json
Windows (Installer von claude.ai)%APPDATA%\Claude\claude_desktop_config.json
Windows (Microsoft Store / WinGet / MSIX)%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
Linux (inoffizielle Builds)~/.config/Claude/claude_desktop_config.json

Existiert die Datei noch nicht, legen Sie sie einfach im entsprechenden Ordner an. Achten Sie unter Windows besonders auf den Unterschied zwischen dem direkten Installer und der Store-Version. Wer die falsche Datei bearbeitet, wundert sich später, warum Claude Desktop den neu eingetragenen Server einfach ignoriert. Öffnen Sie die Datei probeweise mit einem Texteditor, um zu sehen, ob bereits Inhalte vorhanden sind, bevor Sie im nächsten Schritt etwas hinzufügen.

Schritt 3: Ersten MCP-Server installieren und verbinden

Der Filesystem-Server ist der klassische Einstieg, weil er ohne API-Schlüssel funktioniert und sofort einen greifbaren Effekt zeigt: Claude kann danach Dateien in einem von Ihnen freigegebenen Ordner lesen und bearbeiten. Tragen Sie folgenden Block in Ihre claude_desktop_config.json ein und passen Sie den Pfad an Ihr Projektverzeichnis an.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/ihrname/Projekte"
      ]
    }
  }
}

Speichern Sie die Datei und starten Sie Claude Desktop komplett neu, nicht nur das Fenster schließen, sondern die Anwendung wirklich beenden. Nach dem Neustart sehen Sie in der Eingabemaske ein kleines Werkzeug-Symbol. Klicken Sie darauf, und der Filesystem-Server sollte dort mit den verfügbaren Werkzeugen auftauchen. Fragen Sie Claude anschließend testweise, welche Dateien im freigegebenen Ordner liegen. Antwortet die KI mit einer echten Dateiliste, war die Einrichtung erfolgreich.

Ausgabebeispiel nach erfolgreicher Verbindung

Nutzer: Welche Dateien liegen in meinem Projektordner?

Claude: Ich sehe folgende Einträge in /Users/ihrname/Projekte:
- README.md
- package.json
- src/ (Verzeichnis mit 12 Dateien)
- .gitignore

Möchten Sie, dass ich eine bestimmte Datei öffne oder analysiere?

Schritt 4: Claude Code in der Kommandozeile mit MCP verbinden

Claude Code, die CLI-Variante von Anthropic, nutzt dasselbe MCP-Konzept wie Claude Desktop, verwaltet Server aber über eigene Befehle statt über eine manuell editierte Datei. Das hat einen praktischen Vorteil: Sie können Server pro Projekt oder global für alle Projekte hinzufügen, ohne eine JSON-Datei von Hand zu pflegen.

# Server für das aktuelle Projekt hinzufügen
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ./

# Alle konfigurierten Server auflisten
claude mcp list

# Details zu einem einzelnen Server anzeigen
claude mcp get filesystem

Details zur MCP-Integration von Claude Code finden Sie in der offiziellen Anthropic-Dokumentation. Ein Vorteil von Claude Code gegenüber Claude Desktop: Serverdefinitionen lassen sich zwischen beiden Werkzeugen wiederverwenden, weil beide auf dasselbe zugrunde liegende Konfigurationsmodell setzen. Wenn Sie also bereits einen funktionierenden Eintrag in claude_desktop_config.json haben, können Sie Befehl und Argumente eins zu eins in claude mcp add übernehmen. Praktisch, wenn Sie zwischen Chat-Oberfläche und Terminal-Workflow wechseln, ohne alles doppelt zu pflegen.

Schritt 5: MCP-Server in Cursor einrichten

Cursor unterstützt MCP nativ und dokumentiert die Integration unter docs.cursor.com/context/model-context-protocol. Anders als bei Claude Desktop können Sie hier zwischen einer globalen Konfiguration für alle Projekte und einer projektspezifischen Datei wählen, die Sie ins Repository einchecken und mit dem Team teilen können.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ihr_token_hier"
      }
    }
  }
}

Legen Sie diese Datei für ein einzelnes Projekt unter .cursor/mcp.json ab, für eine globale Konfiguration im Nutzerverzeichnis unter ~/.cursor/mcp.json. Öffnen Sie danach die Einstellungen von Cursor und wechseln Sie zum MCP-Bereich. Dort sehen Sie eine Liste aller erkannten Server mit einem grünen oder roten Punkt, der den Verbindungsstatus anzeigt. Ein roter Punkt bedeutet meistens, dass der Startbefehl fehlgeschlagen ist, dazu mehr im Troubleshooting-Abschnitt weiter unten.

Tragen Sie niemals echte Tokens direkt in eine Datei ein, die Sie ins Repository committen. Nutzen Sie stattdessen Umgebungsvariablen oder ein separates, per .gitignore ausgeschlossenes Konfigurationsfile für sensible Werte, gerade beim projektspezifischen Setup. In Teams hat es sich außerdem bewährt, eine mcp.json.example ohne echte Werte mit einzuchecken, damit neue Teammitglieder sofort sehen, welche Server ein Projekt erwartet, ohne dass echte Zugangsdaten je das Repository berühren.

Schritt 6: GitHub Copilot in VS Code mit MCP verbinden

Microsoft hat MCP-Unterstützung direkt in VS Code eingebaut, dokumentiert unter code.visualstudio.com/docs/copilot/customization/mcp-servers. Damit lässt sich GitHub Copilot im Agent-Modus mit externen Werkzeugen erweitern, ohne dass Sie eine separate Erweiterung installieren müssen.

Öffnen Sie in VS Code die Befehlspalette mit Strg+Umschalt+P (macOS: Cmd+Umschalt+P) und suchen Sie nach “MCP: Add Server”. Der Assistent führt Sie durch die Auswahl von Transporttyp, Befehl und gegebenenfalls Umgebungsvariablen und legt die Konfiguration automatisch in einer projektlokalen .vscode/mcp.json oder in Ihren globalen Benutzereinstellungen ab. Alternativ bearbeiten Sie die Datei direkt:

{
  "servers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "${workspaceFolder}"]
    }
  }
}

Nach dem Speichern zeigt VS Code über dem Server-Eintrag einen kleinen “Start”-Link an. Klicken Sie darauf, um den Server zu starten, und öffnen Sie anschließend den Copilot-Chat im Agent-Modus. Die verfügbaren Werkzeuge des Servers erscheinen dort in der Werkzeugliste, erkennbar an einem kleinen Schraubenschlüssel-Symbol neben dem Eingabefeld.

Schritt 7: MCP in JetBrains-IDEs aktivieren

JetBrains hat MCP-Unterstützung in seine IDEs integriert, dokumentiert unter jetbrains.com/help/idea/mcp-server.html. Öffnen Sie in IntelliJ IDEA, PyCharm oder einer anderen JetBrains-IDE die Einstellungen, navigieren Sie zu den KI-Assistenten-Optionen und suchen Sie dort den Abschnitt für Model Context Protocol.

  • Öffnen Sie Settings beziehungsweise Preferences über das Zahnrad-Symbol oder Strg+Alt+S
  • Navigieren Sie zu Tools, dann zu AI Assistant oder Junie, je nach installiertem Plugin
  • Wählen Sie den MCP-Bereich und klicken Sie auf “Server hinzufügen”
  • Tragen Sie Befehl und Argumente analog zu den bisherigen Beispielen ein, oder fügen Sie eine bestehende JSON-Konfiguration per Import ein
  • Bestätigen Sie und prüfen Sie den Verbindungsstatus im selben Dialog

Ein Detail, das viele übersehen: JetBrains-IDEs starten Node-basierte MCP-Server manchmal mit einer anderen PATH-Umgebung als Ihr normales Terminal, besonders wenn Sie die IDE über ein Desktop-Icon statt aus dem Terminal heraus öffnen. Wenn der Server in Cursor oder VS Code funktioniert, aber in der JetBrains-IDE nicht startet, ist ein falsch aufgelöster Node-Pfad die wahrscheinlichste Ursache. Geben Sie in diesem Fall den vollständigen Pfad zur npx-Programmdatei an, statt sich auf die PATH-Variable zu verlassen.

Weil JetBrains-Produkte wie IntelliJ IDEA, PyCharm, WebStorm und Rider dieselbe zugrunde liegende Plattform teilen, lässt sich die MCP-Konfiguration in der Regel unverändert zwischen diesen Anwendungen übertragen. Wechseln Sie also beispielsweise von IntelliJ IDEA zu PyCharm, können Sie dieselbe Server-Liste exportieren und im neuen Programm importieren, statt jede Umgebung von Grund auf neu einzurichten.

Schritt 8: GitHub-MCP-Server mit Access Token konfigurieren

Nach dem Dateisystem ist der GitHub-Server meist der zweite Server, den Entwickler einrichten. Er erlaubt es dem KI-Assistenten, Issues zu lesen, Pull Requests zu kommentieren oder Repository-Metadaten abzufragen, je nachdem, welche Berechtigungen Sie dem Token mitgeben.

Erstellen Sie zunächst in Ihren GitHub-Kontoeinstellungen unter “Developer settings” ein feingranulares Personal Access Token. Beschränken Sie es auf genau die Repositories, die der Assistent tatsächlich braucht, und vergeben Sie nur Lesezugriff, wenn Schreibrechte nicht nötig sind. Tragen Sie das Token danach als Umgebungsvariable in die Serverkonfiguration ein:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_ihr_token_hier"
      }
    }
  }
}

Speichern Sie das Token niemals im Klartext in einer Datei, die Sie versionieren. Nutzen Sie, wo das Tool es erlaubt, eine lokale .env-Datei außerhalb des Repositorys oder den Secret-Manager Ihres Betriebssystems. Rotieren Sie das Token außerdem regelmäßig und widerrufen Sie es sofort, sobald Sie den Verdacht haben, dass es kompromittiert wurde.

Welche Server-Kategorien gibt es sonst noch?

Filesystem und GitHub decken die zwei häufigsten Einstiegsszenarien ab, sind aber bei Weitem nicht alles, was im MCP-Ökosystem verfügbar ist. In der Praxis begegnen Ihnen vor allem vier weitere Kategorien.

  • Datenbank-Server, die lesenden oder schreibenden Zugriff auf Postgres, MySQL oder andere Datenbanken erlauben, meist mit einer Verbindungszeichenfolge als Umgebungsvariable
  • Browser-Automatisierungs-Server, die einen Assistenten Webseiten aufrufen, Formulare ausfüllen oder Screenshots erstellen lassen
  • Kommunikations-Server für Chat-Tools oder Ticketsysteme, die Nachrichten lesen oder neue Einträge anlegen können
  • Cloud- und Infrastruktur-Server, die von Hosting-Anbietern selbst bereitgestellt werden, um deren APIs direkt aus dem Editor heraus ansprechbar zu machen

Wichtig für die Einordnung: Nicht jeder Server, der im Netz kursiert, stammt aus dem offiziellen modelcontextprotocol-Namespace. Viele Anbieter veröffentlichen eigene, community-gepflegte Server unter ihrem eigenen npm-Scope. Das ist grundsätzlich kein Problem, erhöht aber die Sorgfaltspflicht bei der Auswahl. Bevorzugen Sie Server mit sichtbarer Wartungshistorie, klarer Lizenz und einer Dokumentation, die genau beschreibt, welche Daten der Server liest oder verändert, bevor Sie ihn mit produktiven Zugangsdaten verbinden.

Für den Einstieg reicht es völlig, sich auf zwei bis drei Server zu beschränken, die genau zu Ihrem Alltag passen. Ein Backend-Entwickler profitiert vermutlich mehr von einem Datenbank-Server als von einem Browser-Automatisierungs-Werkzeug, während es bei einem Frontend-Team genau umgekehrt sein kann. Bauen Sie die Sammlung Schritt für Schritt aus, statt am ersten Tag gleich zehn Server gleichzeitig einzurichten, denn jeder zusätzliche Server ist auch eine zusätzliche potenzielle Fehlerquelle beim Debuggen.

Schritt 9: stdio, SSE und Streamable HTTP richtig wählen

MCP unterstützt mehrere Transportarten, und welche Sie wählen, hängt davon ab, ob der Server lokal oder entfernt läuft. Für lokale Werkzeuge, die Sie selbst starten, ist stdio (Standard-Ein- und Ausgabe des Prozesses) der Standardfall und in den meisten Beispielen dieser Anleitung bereits im Einsatz. Für entfernte oder gemeinsam genutzte Server kommen HTTP-basierte Transporte ins Spiel.

Mit der Spezifikation vom 28. Juli 2026 wurde der Protokollkern zustandslos gemacht, wie Google in einem Blogbeitrag zur Skalierung von KI-Agenten-Infrastruktur beschreibt. Das erleichtert es, MCP-Server hinter gewöhnlichen HTTP-Lastverteilern zu betreiben, weil keine langlebige Sitzung mehr pro Client vorgehalten werden muss. In der Praxis heißt das: Wenn Sie einen MCP-Server für ein ganzes Team zentral bereitstellen wollen, statt ihn auf jedem Rechner lokal zu starten, ist ein HTTP-Endpunkt die robustere Wahl.

{
  "mcpServers": {
    "team-tools": {
      "url": "https://mcp.ihrefirma.at/tools"
    }
  }
}

Beachten Sie, dass ältere Server, die noch auf dem Vorgänger-Standard 2025-11-25 basieren, mit dem initialize-Handshake und einer Mcp-Session-Id arbeiten. Diese Version gilt laut der offiziellen Versions-Zeitleiste inzwischen als final, aber überholt. Wenn Sie einen selbst gehosteten oder älteren Server einbinden, prüfen Sie dessen Dokumentation darauf, welche Spezifikationsversion er tatsächlich implementiert, bevor Sie Verbindungsprobleme fälschlich bei Ihrer eigenen Konfiguration suchen.

Schritt 10 bis 12: Einen eigenen MCP-Server mit Node.js bauen

Fertige Server decken viele Fälle ab, aber irgendwann wollen Sie ein internes Tool anbinden, für das es keinen offiziellen Server gibt, etwa ein selbst gebautes Ticketsystem oder eine interne API. Das folgende Beispiel ist ein vollständiges, lauffähiges Mini-Projekt: ein MCP-Server, der ein einziges Werkzeug bereitstellt, das die aktuelle Zeilenzahl einer Datei zurückgibt.

Legen Sie zunächst ein neues Verzeichnis an und initialisieren Sie ein Node-Projekt. Fügen Sie in der package.json noch “type”: “module” hinzu, damit die import-Syntax des Beispiels ohne zusätzliche Konfiguration funktioniert.

mkdir mein-mcp-server
cd mein-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod

Erstellen Sie anschließend eine Datei server.js mit folgendem Inhalt:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { readFileSync } from "node:fs";

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

server.registerTool(
  "zeilen_zaehlen",
  {
    title: "Zeilen zählen",
    description: "Gibt die Anzahl der Zeilen einer Textdatei zurück",
    inputSchema: { pfad: z.string() }
  },
  async ({ pfad }) => {
    const inhalt = readFileSync(pfad, "utf-8");
    const anzahl = inhalt.split("\n").length;
    return {
      content: [{ type: "text", text: `Die Datei hat ${anzahl} Zeilen.` }]
    };
  }
);

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

Schauen wir uns kurz an, was die einzelnen Teile des Codes tun, bevor Sie ihn einbinden. Die McpServer-Instanz meldet Namen und Version des Servers, damit der Host ihn in Protokollen und Menüs sinnvoll beschriften kann. Der Aufruf von registerTool definiert genau ein Werkzeug mit Namen, Titel, Beschreibung und einem mit Zod validierten Eingabeschema, hier ein einzelnes Pflichtfeld namens pfad. Die Handler-Funktion enthält die eigentliche Logik, in diesem Fall das Einlesen der Datei und das Zählen der Zeilenumbrüche, und liefert das Ergebnis in dem von MCP erwarteten content-Format zurück. Der letzte Block verbindet den Server über stdio mit dem aufrufenden Prozess, also genau der Transportart, die auch Claude Desktop und die meisten anderen Hosts standardmäßig erwarten.

Tragen Sie den neuen Server in Ihre bevorzugte Konfiguration ein, egal ob Claude Desktop, Cursor oder VS Code:

{
  "mcpServers": {
    "zeilenzaehler": {
      "command": "node",
      "args": ["/absoluter/pfad/zu/mein-mcp-server/server.js"]
    }
  }
}

Starten Sie Ihr Tool neu und fragen Sie den Assistenten, wie viele Zeilen eine bestimmte Datei hat. Wenn die Antwort eine konkrete Zahl enthält statt einer Fehlermeldung, funktioniert Ihr erster selbst geschriebener MCP-Server. Von hier aus lässt sich das Muster beliebig erweitern, etwa um Werkzeuge, die gegen eine interne REST-API sprechen, eine Datenbankabfrage ausführen oder eine E-Mail versenden, jeweils mit eigenem inputSchema und eigener Handler-Funktion.

Schritt 13: Mehrere Server verwalten, Rechte einschränken, Sicherheit konfigurieren

Sobald Sie mehr als zwei oder drei Server im Einsatz haben, wird Übersicht zur eigenen Aufgabe. Ein paar Regeln, die sich in der Praxis bewährt haben.

  • Geben Sie jedem Filesystem-Server nur die konkreten Ordner frei, die er wirklich braucht, statt des gesamten Home-Verzeichnisses
  • Trennen Sie produktive Zugangsdaten von Test-Tokens, idealerweise über separate Umgebungsvariablen-Dateien pro Projekt
  • Deaktivieren Sie Server, die Sie gerade nicht aktiv nutzen, statt sie dauerhaft im Hintergrund laufen zu lassen
  • Prüfen Sie bei Servern von Drittanbietern, wer das Paket veröffentlicht hat, bevor Sie es per npx ausführen, da npx Code aus dem npm-Registry ungeprüft startet
  • Dokumentieren Sie im Team, welche Server projektweit über eine eingecheckte .cursor/mcp.json oder .vscode/mcp.json laufen und welche rein lokal bei Einzelpersonen liegen

Gerade der letzte Punkt zur Prüfung von Drittanbieter-Paketen verdient mehr Aufmerksamkeit, als ihm im Alltag oft geschenkt wird. Ein MCP-Server ist im Kern ein Programm mit denselben Rechten wie Ihr Nutzerkonto. Ein bösartiger oder schlecht programmierter Server kann Dateien lesen, verändern oder Netzwerkverbindungen aufbauen, ohne dass die KI selbst davon “weiß”, dass etwas schiefläuft. Halten Sie sich deshalb möglichst an offizielle Pakete aus dem modelcontextprotocol-Namespace oder an Server von Anbietern, deren Code Sie selbst einsehen können.

MCP-Unterstützung im Vergleich: Welches Tool kann was?

Die folgende Übersicht fasst zusammen, wie die wichtigsten Coding-Tools MCP-Server einbinden und wo die Konfiguration jeweils liegt.

ToolKonfigurationsdateiGeltungsbereichBevorzugter Transport
Claude Desktopclaude_desktop_config.jsonGlobal (alle Chats)stdio, URL
Claude CodeVerwaltung über claude mcp addProjekt oder globalstdio, URL
Cursor.cursor/mcp.json oder ~/.cursor/mcp.jsonProjekt oder globalstdio, URL
VS Code (GitHub Copilot).vscode/mcp.json oder BenutzereinstellungenProjekt oder globalstdio, SSE, HTTP
JetBrains-IDEsIDE-Einstellungen, KI-Assistent-BereichProjekt oder globalstdio, URL

Auffällig ist, dass sich das grundlegende Muster über alle Tools hinweg ähnelt: ein Objekt mit benannten Servern, jeweils mit Startbefehl, Argumenten und optionalen Umgebungsvariablen oder einer URL. Wenn Sie einmal verstanden haben, wie eine Konfiguration für ein Tool aufgebaut ist, übertragen Sie das Muster mit wenigen Anpassungen auf die anderen. GitHub selbst treibt die Verbreitung des Standards zusätzlich voran: Wie shattered.io berichtete, hat GitHub sein Copilot-Agent-Plugin-Ökosystem auf Basis von MCP ausgebaut und dabei mehrere Launch-Partner gewonnen.

Die 5 häufigsten Fehler beim MCP-Setup

Bevor Sie in die ausführliche Fehlerbehebung einsteigen, hier die Stolperfallen, die in der Praxis am öftesten auftreten und sich mit wenig Aufwand vermeiden lassen.

  • Falscher Konfigurationspfad unter Windows. Wer die Store-Version von Claude Desktop nutzt, aber die Installer-Pfadangabe bearbeitet, editiert eine Datei, die die Anwendung nie liest.
  • Anwendung nicht vollständig neu gestartet. Ein Klick auf das Schließen-Symbol beendet Claude Desktop unter macOS und Windows oft nicht wirklich, die App läuft im Hintergrund weiter und liest die geänderte Konfiguration nicht neu ein.
  • Relative statt absolute Pfade im Startbefehl. Ein Pfad wie ./daten funktioniert im Terminal, aber nicht, wenn der Editor den Serverprozess aus einem anderen Arbeitsverzeichnis heraus startet.
  • Tokens direkt im Repository eingecheckt. Eine mcp.json mit Klartext-Token landet über einen unbedachten Commit schnell öffentlich einsehbar in der Versionshistorie.
  • Veraltete Server-Version bei neuer Protokollspezifikation. Nach dem Wechsel auf die Spezifikation 2026-07-28 brechen Server, die noch auf den alten initialize-Handshake setzen, ohne aussagekräftige Fehlermeldung ab.

Was diese fünf Fehler verbindet: Keiner davon zeigt sich mit einer klaren, selbsterklärenden Fehlermeldung. Die meisten Editoren melden schlicht “Server nicht erreichbar” oder zeigen ein rotes Symbol, ohne die eigentliche Ursache zu benennen. Wer die Liste oben im Kopf hat, spart sich beim Debuggen viel Zeit, weil er gezielt die wahrscheinlichsten Ursachen zuerst prüft, statt bei null anzufangen.

Troubleshooting: Die häufigsten Probleme lösen

Auch mit sorgfältiger Einrichtung läuft nicht immer alles beim ersten Versuch. Die folgende Tabelle deckt die Probleme ab, die in Support-Foren und Community-Kanälen am häufigsten gemeldet werden.

ProblemWahrscheinliche UrsacheLösung
Server erscheint nicht im Werkzeug-MenüAnwendung wurde nicht vollständig neu gestartetProzess im Task-Manager oder Aktivitätsanzeige komplett beenden, dann neu öffnen
Rotes Statuslicht / “failed to start”Node oder npx nicht im PATH der IDE auffindbarVollständigen Pfad zu npx angeben, mit which npx oder where npx ermitteln
JSON-Syntaxfehler beim SpeichernFehlendes Komma oder überzähliges schließendes ZeichenDatei durch einen JSON-Validator laufen lassen, bevor die App neu gestartet wird
Server startet, aber Werkzeuge fehlenFalsche oder fehlende Berechtigungen im TokenToken-Scopes in den Kontoeinstellungen prüfen und bei Bedarf erweitern
“EACCES” oder Berechtigungsfehler beim DateizugriffFreigegebener Pfad existiert nicht oder Nutzer hat keine LeserechtePfad auf Tippfehler prüfen und Dateiberechtigungen mit ls -l bzw. Eigenschaften-Dialog kontrollieren
Verbindung bricht nach kurzer Zeit abServer implementiert noch die alte, sitzungsbasierte SpezifikationAktuelle Serverversion installieren, die die Spezifikation 2026-07-28 unterstützt
Doppelte Werkzeugnamen in mehreren ServernZwei Server registrieren ein Werkzeug mit identischem NamenEinen der beiden Server deaktivieren oder Werkzeugnamen im eigenen Server umbenennen
Hohe Latenz bei jeder AnfrageServer wird bei jedem Aufruf per npx neu heruntergeladen statt gecachtPaket einmalig global installieren und den Befehl auf den lokalen Pfad umstellen
Umgebungsvariable kommt beim Server nicht anenv-Block falsch verschachtelt oder Tippfehler im VariablennamenSchreibweise exakt mit der Dokumentation des jeweiligen Servers abgleichen

Wenn keiner dieser Punkte weiterhilft, aktivieren Sie in Ihrem Editor den Debug- oder Log-Modus für MCP, falls vorhanden. VS Code etwa zeigt in einem eigenen Output-Kanal an, mit welchem exakten Befehl der Server gestartet wurde. Diesen Befehl können Sie dann direkt im Terminal ausführen und die Fehlermeldung des Serverprozesses selbst lesen, statt sich auf die oft knappe Fehleranzeige der IDE zu verlassen. Dieser Zwischenschritt klingt banal, löst in der Praxis aber einen großen Teil der Fälle, in denen die IDE selbst nur ein generisches “Verbindung fehlgeschlagen” anzeigt.

Fortgeschrittene Tipps für den produktiven Einsatz

Sobald das Grundsetup steht, lohnt sich ein Blick auf ein paar Praktiken, die den Unterschied zwischen einem Spielzeug-Setup und einem Werkzeug machen, das Sie täglich nutzen.

Versionieren Sie projektweite MCP-Konfigurationen im Repository, aber trennen Sie sie strikt von Geheimnissen. Eine Datei wie .cursor/mcp.json kann eingecheckt werden, solange sie nur Platzhalter für Umgebungsvariablen enthält, während die eigentlichen Werte in einer lokalen, per .gitignore ausgeschlossenen .env-Datei liegen. So bekommt jedes Teammitglied dieselbe Werkzeugliste, ohne dass Zugangsdaten geteilt werden müssen.

Nutzen Sie für produktiv genutzte, gemeinsam geteilte Server einen zentralen HTTP-Endpunkt statt lokaler stdio-Prozesse auf jedem Rechner. Das reduziert die Wartungslast, weil Updates nur an einer Stelle eingespielt werden müssen, und passt außerdem besser zur zustandslosen Architektur der aktuellen Spezifikation, die genau für diesen Skalierungsfall entworfen wurde.

Halten Sie die Zahl gleichzeitig aktiver Server pro Projekt bewusst klein. Jeder zusätzliche Server erweitert nicht nur die Werkzeugliste, sondern auch den Kontext, den das Sprachmodell bei jeder Anfrage mitverarbeiten muss. In der Praxis führt eine zu lange Werkzeugliste dazu, dass der Assistent das falsche Werkzeug wählt oder Anfragen langsamer beantwortet. Aktivieren Sie deshalb nur die Server, die für die aktuelle Aufgabe wirklich relevant sind, und deaktivieren Sie den Rest bei Bedarf projektweise. Ein einfacher Test in der Praxis: Wenn Sie selbst nicht mehr aus dem Kopf aufzählen können, welche Server gerade aktiv sind und wofür Sie diese eingerichtet haben, ist es Zeit, die Liste aufzuräumen.

Schließlich: Beobachten Sie das offizielle Änderungsprotokoll der Spezifikation. Der Wechsel von der Vorgängerversion 2025-11-25 zur aktuellen Version 2026-07-28 war mit dem Wegfall des initialize-Handshakes eine echte Breaking Change. Wer eigene Server betreibt, sollte solche Ankündigungen nicht erst bemerken, wenn ein Kollege meldet, dass die Verbindung plötzlich nicht mehr funktioniert.

Ein letzter Tipp aus der Praxis: Legen Sie sich früh eine kleine, private Sammlung an Servern an, die Sie persönlich für vertrauenswürdig halten, statt bei jedem neuen Projekt erneut im Netz zu suchen. Eine kurze interne Notiz mit Paketname, Zweck und benötigten Umgebungsvariablen erspart Ihnen und Kolleginnen und Kollegen später viel Zeit, gerade wenn mehrere Personen dieselben Werkzeuge in unterschiedlichen Projekten wiederverwenden. So wird aus einem einmaligen Setup-Aufwand ein wiederverwendbarer Baustein für alle künftigen Projekte.

Governance und Sicherheit: Was Sie im Blick behalten sollten

MCP bleibt zwar ein offener Standard, wird aber von Anthropic geleitet und über ein zentrales Repository koordiniert. Änderungen an SDKs für verschiedene Programmiersprachen werden abgestimmt veröffentlicht, was für Konsistenz sorgt, aber auch bedeutet, dass Sie als Betreiber eigener Server die Release-Notes im Blick behalten müssen, um keine Breaking Changes zu verpassen. Diese Kombination aus offener Spezifikation und zentraler Steuerung durch einen einzelnen Anbieter ist kein Zufall, sondern ein bewusster Kompromiss zwischen schneller Weiterentwicklung und einheitlicher Umsetzung über alle Editoren hinweg.

Aus Sicherheitssicht gilt für MCP-Server dieselbe Grundregel wie für jede andere Software, die mit externen Daten oder Zugangsdaten hantiert: minimale Rechte, nachvollziehbare Herkunft und regelmäßige Kontrolle. Prüfen Sie insbesondere bei Community-Servern, die nicht aus dem offiziellen modelcontextprotocol-Namespace stammen, wer den Code pflegt und wie aktiv das Projekt ist. Ein verwaistes Paket, das seit Monaten keine Updates mehr erhalten hat, ist ein schlechterer Kandidat für produktiven Einsatz als ein aktiv gepflegter, offiziell gelisteter Server.

Ein Punkt, der in Teams gerne untergeht: MCP-Server laufen typischerweise unter demselben Betriebssystem-Nutzerkonto wie die IDE selbst, es gibt also standardmäßig keine automatische Sandbox, die einen Server daran hindert, mehr zu tun, als sein dokumentierter Zweck vorsieht. Wenn Sie in einem regulierten Umfeld arbeiten, etwa mit Kundendaten oder Zugriff auf produktive Systeme, lohnt sich ein zusätzlicher Blick auf Betriebssystem-Mechanismen wie eingeschränkte Benutzerkonten, Container oder Firewall-Regeln, die den Server selbst dann einhegen, wenn seine Konfiguration einmal zu großzügig ausfällt. Das ist kein MCP-spezifisches Problem, aber die wachsende Zahl an Servern macht es sichtbarer als früher.

Häufig gestellte Fragen zu MCP-Servern

Was ist der Unterschied zwischen einem MCP-Server und einer klassischen API-Integration?
Eine klassische Integration ist meist fest in ein einzelnes Tool eingebaut und funktioniert nur dort. Wechseln Sie den Editor, müssen Sie die Integration neu bauen. Ein MCP-Server folgt dagegen einer standardisierten Schnittstelle und lässt sich ohne Anpassung mit jedem MCP-fähigen Client verbinden, egal ob Claude, Cursor oder VS Code. Der Aufwand für eine Integration fällt damit nur einmal an, nicht einmal pro Tool.

Brauche ich für jeden MCP-Server einen eigenen API-Schlüssel?
Nicht zwingend. Der Filesystem-Server etwa braucht keinerlei Zugangsdaten, weil er lediglich auf lokale Pfade zugreift. Server, die externe Dienste wie GitHub ansprechen, benötigen dagegen ein passendes Token mit den nötigen Berechtigungen.

Kann ich MCP-Server auf mehreren Rechnern gemeinsam nutzen?
Ja, wenn Sie den Server über einen HTTP-Endpunkt statt über stdio bereitstellen. Die aktuelle, zustandslose Spezifikation von Juli 2026 wurde gezielt darauf ausgelegt, MCP-Server hinter gewöhnlichen Lastverteilern zentral zu betreiben. Für ein kleines Team reicht oft schon ein einzelner virtueller Server, auf dem die wichtigsten internen Werkzeuge laufen, statt dass jede Entwicklerin und jeder Entwickler dieselben Server lokal einzeln startet und pflegt.

Ist MCP nur für Claude gedacht?
Nein. Anthropic hat MCP zwar entwickelt, das Protokoll ist aber als offener, herstellerneutraler Standard konzipiert. Cursor, VS Code mit GitHub Copilot und JetBrains-IDEs unterstützen MCP inzwischen ebenfalls nativ.

Warum funktioniert mein Server in einem Tool, aber nicht im anderen?
Meistens liegt es an unterschiedlich aufgelösten PATH-Umgebungen oder an leicht abweichenden Konfigurationsschlüsseln, etwa mcpServers gegenüber servers. Prüfen Sie den exakten Startbefehl im Log oder Debug-Kanal des jeweiligen Tools.

Wie sicher ist es, einen MCP-Server per npx zu starten?
npx lädt und führt Code aus dem npm-Registry aus, ohne dass Sie ihn vorher manuell prüfen. Das ist bequem, aber kein Ersatz für eine bewusste Entscheidung. Nutzen Sie deshalb bevorzugt offizielle oder gut bekannte Pakete und kontrollieren Sie bei unbekannten Anbietern, wer das Paket veröffentlicht hat und wie viele andere Projekte davon abhängen, bevor Sie es in einem produktiven Projekt einsetzen. Im Zweifel installieren Sie das Paket einmalig manuell und lesen kurz den Quellcode, statt es blind per npx bei jedem Start neu zu laden.

Muss ich meinen eigenen MCP-Server in einer bestimmten Programmiersprache schreiben?
Nein. Offizielle SDKs existieren unter anderem für TypeScript, Python und weitere Sprachen. Das Node.js-Beispiel in dieser Anleitung lässt sich sinngemäß auf jede Sprache übertragen, für die ein MCP-SDK verfügbar ist. Wählen Sie am besten die Sprache, in der Ihr Team ohnehin am produktivsten ist, statt extra für den MCP-Server eine neue Sprache zu lernen.

Was passiert, wenn die MCP-Spezifikation sich erneut ändert?
Client und Server handeln die unterstützte Protokollversion inzwischen pro Anfrage aus, statt sie einmalig beim Verbindungsaufbau festzulegen. Das erleichtert Übergänge zwischen Spezifikationsversionen, ersetzt aber nicht die Notwendigkeit, veraltete Server rechtzeitig zu aktualisieren.