MCP Server für Claude Code: Was ist das und welche du brauchst (2026)

Du arbeitest mit Claude Code im Terminal und merkst schnell: Das Modell ist brillant beim Coden, aber es lebt in seiner eigenen Blase. Es kennt deine Datenbank nicht, kann nicht in deinem Code auf GitHub nachschauen und weiß nichts über die aktuelle Doku eines Tools. Genau hier kommt ein MCP Server ins Spiel: Er ist die Brücke, die Claude Code mit deinen echten Tools und Datenquellen verbindet, ohne dass du jedes Mal Kontext manuell reinkopieren musst. In diesem Artikel erfährst du, was ein MCP Server ist, was er dir konkret bringt, wie du ihn in vier Varianten einbindest – und welche Server du wirklich brauchst.

Was ist ein MCP Server (Model Context Protocol)?

MCP steht für Model Context Protocol – ein offener Standard, den Anthropic entwickelt hat, um KI-Modelle wie Claude mit externen Tools und Daten zu verbinden. Du kannst dir das wie eine Art „USB-C für KI“ vorstellen: Statt für jede Integration eine eigene proprietäre Schnittstelle zu bauen, gibt es einen einheitlichen Standard, an den sich alle halten. Technisch sitzt MCP auf JSON-RPC 2.0 auf – aber keine Sorge, davon merkst du im Alltag exakt nichts.

Ein MCP Server ist dabei ein kleines Programm, das eine bestimmte Fähigkeit oder Datenquelle bereitstellt – zum Beispiel Zugriff auf dein Dateisystem, deine Postgres-Datenbank oder die GitHub-API. Claude Code ist der Client, der sich mit diesen Servern verbindet. Das Schöne: Weil MCP ein offener Standard ist, funktionieren dieselben Server nicht nur in Claude Code, sondern in jedem MCP-fähigen Client.

Und der Standard ist längst kein Nischenprojekt mehr. Anthropic hat MCP im November 2024 veröffentlicht – ein Jahr später zählte das Projekt bereits über 97 Millionen monatliche SDK-Downloads und rund 10.000 aktive Server, mit Client-Support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und VS Code. Das ist eine Adoptionsgeschwindigkeit, die man in der Softwarewelt selten sieht.

Die drei Schichten: Host, Client, Server

Klingt ganz schön kompliziert? Ist es nicht. MCP besteht aus genau drei Rollen, und wenn du die einmal verstanden hast, ergibt der Rest sich von selbst:

• MCP Host: die KI-Anwendung mit dem Modell drin – also Claude Code, Cursor oder Windsurf.
• MCP Client: der Connector im Host, der eine 1:1-Session zu genau einem Server aufbaut.
• MCP Server: der externe Dienst, der die Fähigkeit liefert – GitHub, PostgreSQL, Playwright und so weiter.

Du selbst arbeitest praktisch immer nur mit dem Host. Client und Server laufen im Hintergrund und reden miteinander, während du einfach deine Prompts tippst.

Tools, Resources und Prompts – die drei Primitive

Jeder MCP Server kann bis zu drei Dinge anbieten. Tools sind aufrufbare Funktionen – also Aktionen, die Claude ausführen kann, etwa „erstelle ein Issue“ oder „führe diese Query aus“. Resources sind lesbare Daten, die Claude in den Kontext holen kann. Und Prompts sind vorgefertigte Workflow-Templates, die ein Server mitliefert.

In der Praxis drehen sich 90 Prozent um die Tools. Wenn dir jemand sagt, ein Server „hat 15 Tools“, dann heißt das: Claude kann 15 verschiedene Aktionen über diesen Server auslösen. Genau deshalb ist auch Sparsamkeit angesagt – dazu später mehr.

Was bringt ein MCP Server für Claude Code?

Ohne MCP musst du Claude Code alles mundgerecht servieren: Datei-Inhalte kopieren, Fehlermeldungen einfügen, Datenbank-Schemas beschreiben. Mit einem MCP Server holt sich Claude diese Informationen selbst – kontrolliert, nachvollziehbar und genau dann, wenn sie gebraucht werden.

Konkret heißt das:

• Weniger Copy-Paste: Claude liest selbst aus deinen Datenquellen, statt dass du Kontext zusammensammelst.
• Mehr Aktionen: Claude kann nicht nur lesen, sondern auch handeln – etwa ein GitHub-Issue erstellen oder eine Query gegen die Datenbank fahren.
• Aktueller Kontext: Statt auf dem Trainingsstand des Modells (etwa Opus 5, Sonnet 5 oder Haiku 4.5) festzuhängen, greift Claude auf Live-Daten zu.
• Wiederverwendbarkeit: Einmal eingerichtet, steht ein Server in all deinen Projekten oder deinem Team zur Verfügung.

Der eigentliche Aha-Moment kommt aber erst, wenn mehrere Server zusammenspielen. Du sagst einmal „schau in die aktuelle Doku, bau mir die Komponente, teste sie im Browser und öffne einen Pull Request“ – und Claude verkettet dafür vier verschiedene Server, ohne dass du zwischendurch die Tabs wechselst. Das ist kein Autocomplete mehr. Das ist ein Kollege.

Wie bindest du einen MCP Server in Claude Code ein?

Es gibt vier Wege, und du brauchst nicht alle. Ich zeig dir trotzdem jeden kurz, damit du weißt, wann welcher Sinn ergibt.

Methode 1: Der CLI-Befehl (mein Favorit)

Der schnellste Weg läuft über das Terminal. Ein Befehl, fertig:

claude mcp add context7 -- npx -y @upstash/context7-mcp

Braucht der Server einen Key, hängst du ihn per -e beziehungsweise --env dran:

claude mcp add slack -e SLACK_BOT_TOKEN=xoxb-dein-token -- npx -y @modelcontextprotocol/server-slack

Ein Detail, das gern für Frust sorgt: Alle Optionen müssen vor den Servernamen. Das doppelte -- trennt dann die Claude-Flags vom eigentlichen Startbefehl des Servers. Wenn du eine kryptische Fehlermeldung bekommst, liegt es in neun von zehn Fällen daran.

Methode 2: Die .mcp.json im Projekt

Für reproduzierbare Setups legst du eine .mcp.json in den Projekt-Root. So weiß jedes Teammitglied (und jede neue Session) sofort, welche Server gebraucht werden. Ein einfaches Beispiel für einen Filesystem- und einen GitHub-Server:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/du/projekte"
      ]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    }
  }
}

Die Felder sind schnell erklärt: command ist der Startbefehl (npx, uvx, docker oder ein Pfad), args die Argumente, env die Umgebungsvariablen, type der Transport (stdio ist Standard, daneben gibt es http, sse und ws) und url die Adresse bei Remote-Servern. Optional setzt du noch ein timeout in Millisekunden.

Methode 3: Docker

Manche Server laufen am saubersten im Container – gerade dann, wenn du sie vom Rest deines Systems abschotten willst. Das sieht dann so aus:

{
  "mcpServers": {
    "postgres": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "DATABASE_URL", "mcp/postgres"]
    }
  }
}

Methode 4: Remote über HTTP

Immer mehr Anbieter hosten ihren MCP Server selbst. Dann musst du lokal gar nichts installieren, sondern verbindest dich nur:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Braucht der Dienst ein Token statt eines Browser-Logins, hängst du einen Header dran: --header "Authorization: Bearer DEIN_PAT". Bei OAuth-Diensten läuft die Anmeldung dagegen bequem über den Browser – du tippst nur /mcp in deiner Session, wählst den Server aus und klickst auf „Authenticate“.

Der /mcp-Command: dein Kontrollzentrum

Apropos: Tippe in deiner Claude-Code-Session einfach /mcp ein. Du bekommst eine Übersicht aller konfigurierten Server, ihren Verbindungsstatus, die Anzahl der Tools und kannst OAuth-Logins direkt abwickeln. Das ist der schnellste Weg, um zu prüfen, ob alles läuft. Für alles andere gibt es die CLI:

• claude mcp list – zeigt alle konfigurierten Server.
• claude mcp get <name> – zeigt Details zu einem Server inklusive Scope.
• claude mcp remove <name> – wirft ihn wieder raus.
• claude doctor – prüft deine Installation, wenn gar nichts mehr geht.

Scopes: local, project oder user?

Jetzt kommt der Teil, den viele überspringen – und sich danach wundern, warum ein Server im einen Projekt da ist und im anderen nicht. Claude Code kennt drei Ablageorte:

• local (Standard): landet in ~/.claude.json, gilt nur für das aktuelle Projekt und wird nicht geteilt. Perfekt für Experimente und persönliche Zugangsdaten.
• project: schreibt in die .mcp.json im Repo und wird per Git mit dem Team geteilt. Dafür setzt du --scope project.
• user: liegt ebenfalls in ~/.claude.json, gilt aber für alle deine Projekte. Dafür setzt du --scope user.

Gibt es denselben Server in mehreren Scopes, gewinnt der spezifischere. Die Reihenfolge lautet: local schlägt project, project schlägt user, danach kommen Plugin-Server und ganz zuletzt die Connectoren aus Claude.ai. Meine Faustregel: GitHub und Context7 auf user, weil ich die überall brauche. Datenbank und projektspezifisches Zeug auf local oder project.

Die nützlichsten MCP Server für den Alltag

Es gibt inzwischen weit über zehntausend öffentliche MCP Server. Verdammt viele! Du musst aber nicht alles ausprobieren. Diese Handvoll deckt die meisten Anwendungsfälle für Solopreneure und Entwickler ab.

Filesystem

Der Filesystem-Server aus dem offiziellen Repo gibt Claude kontrollierten Zugriff auf bestimmte Verzeichnisse – lesen, schreiben, durchsuchen. Praktisch, wenn du außerhalb des aktuellen Projektordners arbeiten oder den Zugriff explizit auf bestimmte Pfade begrenzen willst. Der Pfad steht direkt im Startbefehl, und genau da liegt auch die Sicherheitsgrenze.

Context7

Wenn ich nur einen einzigen Drittanbieter-Server empfehlen dürfte, wäre es Context7 von Upstash. Er zieht versionsspezifische Dokumentation direkt in den Prompt – und löst damit das nervigste Problem beim KI-Coding: halluzinierte APIs, die es in deiner Version schlicht nicht gibt. Du schreibst einfach use context7 to show ... in deinen Prompt, und Claude arbeitet mit der echten Doku statt mit Erinnerungen aus dem Training. Damit habe ich die besten Erfahrungen gemacht.

GitHub

Mit dem offiziellen GitHub-Server kann Claude Issues und Pull Requests lesen und erstellen, Repos durchsuchen und Code-Reviews unterstützen. Für alle, die ihren Workflow rund um GitHub organisieren, ist das einer der wertvollsten Server überhaupt. Er läuft entweder remote über HTTP oder lokal – und du solltest ihn auf möglichst wenige Repos beschränken.

Playwright

Der Playwright-Server von Microsoft gibt Claude einen echten Browser. Klingt spielerisch, ist aber enorm nützlich: Claude kann die Seite, die es gerade gebaut hat, selbst öffnen, anklicken, testen und den Fehler direkt fixen. Installiert ist er mit npx @playwright/mcp@latest. Wer einmal gesehen hat, wie Claude einen eigenen Bug im Browser reproduziert, will das nicht mehr missen.

Datenbank: Supabase oder Postgres

Ein Datenbank-Server lässt Claude dein Schema verstehen und Queries ausführen. Für Supabase gibt es einen offiziellen Server, für klassisches Postgres nutzt du zum Beispiel @bytebase/dbhub mit einem DSN. Gerade beim Debuggen oder beim Schreiben komplexer SQL-Abfragen spart das enorm Zeit. Tipp: Nutze unbedingt einen read-only Zugang und zeig nicht auf Produktion. Ein schreibfähiger DB-Zugang in einem KI-Tool ist ein Produktionsvorfall mit Ansage.

Sentry und Web/Fetch

Sentry gibt es als Remote-Server – damit springt Claude vom Stacktrace direkt in die betroffene Datei, statt dass du zwischen Browser und Editor pendelst. Und ein Fetch-Server (etwa uvx mcp-server-fetch) erlaubt Claude, Webseiten abzurufen und in nutzbaren Kontext umzuwandeln. Daneben existieren offizielle Server für Elasticsearch, Grafana, AWS, Cloudflare, Stripe, Notion und Figma. Bei Stripe gilt: nur restricted Test-Keys, niemals Live-Schlüssel.

Sicherheit: Nur vertrauenswürdige MCP Server nutzen

Ein MCP Server bekommt echte Rechte – er kann Dateien lesen, Datenbanken abfragen oder API-Calls absetzen. Das ist mächtig, aber auch ein Einfallstor, wenn du unbedacht vorgehst. Und das ist leider kein theoretisches Risiko mehr: Allein im Januar und Februar 2026 wurden über 30 CVEs gegen das MCP-Ökosystem gemeldet, darunter eine Command-Injection-Lücke im Paket mcp-remote mit CVSS-Score 9.6 – bei mehr als 437.000 Downloads vor der Veröffentlichung. Wer mitverfolgen will, was gerade auffällt, findet beim Vulnerable MCP Project eine laufende Übersicht.

Das Kernprinzip heißt Least Privilege.

Diese fünf Risiken solltest du kennen:

• Zu breiter Zugriff: Zeig den Filesystem-Server niemals auf dein Home-Verzeichnis oder gar /. Nur den Projektordner. Datenbanken read-only und nicht auf Produktion. GitHub-Token auf die nötigen Repos begrenzen.
• Secrets in der Config: Kein Token als Literal in der .mcp.json, sondern konsequent ${ENV_VAR}. Sonst liegt dein Key irgendwann im öffentlichen Repo.
• Prompt Injection über zurückgegebene Inhalte: Alles, was ein Server zurückliefert – ein GitHub-Issue, eine Webseite, ein Kommentar – landet im Kontext und kann Anweisungen enthalten. Schreibende Aktionen deshalb manuell bestätigen und lesende Zugriffe bevorzugen.
• Untrusted Servers: Bei tausenden öffentlichen Servern ist nicht jeder gut gemeint. Nimm offizielle oder aktiv gepflegte Projekte und wirf bei allem anderen vorher einen Blick in den Code.
• Command Execution: Nutze PreToolUse-Hooks und die Permission-Regeln von Claude Code. Damit erlaubst oder blockierst du einzelne Tools gezielt über das Muster mcp__<server>__<tool>.

Das strukturell fieseste Problem ist übrigens Tool Poisoning: Ein Angreifer versteckt Anweisungen in der Beschreibung eines Tools. Die liest das Modell als vertrauenswürdigen Text – und befolgt sie. Deshalb: „Always Allow“ ausschalten, hochprivilegierte Server isolieren und lieber einmal mehr selbst bestätigen. Klingt paranoid? Ist es nicht. Es kostet dich zwei Sekunden pro Tool-Call.

Häufige Fehler – und wie du sie in einer Minute löst

Die meisten Probleme beim Einbinden sind erstaunlich banal. Hier die Klassiker, die dir garantiert begegnen:

• „Server failed to connect“: Der Server ist abgestürzt oder die Authentifizierung fehlt. Tipp /mcp und schau dir den Status an, prüfe bei stdio den Startbefehl und bei HTTP die URL.
• „command not found: npx“: Du hast kein Node auf dem System. Node 18 oder neuer installieren, fertig.
• „Tool not found“: Der Server läuft, registriert aber keine Tools – meist fehlt eine Umgebungsvariable wie ein API-Key. In /mcp siehst du die Tool-Anzahl.
• ENOENT: Das Paket existiert nicht. Meistens ein Tippfehler im Paketnamen.
• Timeout: Der Server braucht zu lange beim Start. Setz MCP_TIMEOUT=10000 oder das timeout-Feld in der Config.
• URL, aber kein Typ: Bei Remote-Servern gehört "type": "http" dazu. Fehlt das, passiert nichts.
• Nichts verbindet sich nach einer Änderung: Claude Code liest die .mcp.json beim Session-Start. Session beenden, neu starten – und es läuft.

Und für alle unter Windows: Bei stdio-Servern brauchst du in der Regel cmd /c npx statt nur npx. Das ist so ein Detail, an dem man ohne Vorwarnung eine halbe Stunde verliert.

Was sich bei MCP gerade ändert

MCP ist erwachsen geworden – und das im Wortsinn. Am 9. Dezember 2025 hat Anthropic das Protokoll an die Agentic AI Foundation übergeben, einen Fonds unter dem Dach der Linux Foundation, mitgegründet von Anthropic, Block und OpenAI und unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Für dich heißt das vor allem eins: MCP gehört keiner einzelnen Firma mehr. Der Standard steht jetzt unter derselben neutralen Verwaltung wie Kubernetes oder Node.js, und Änderungen laufen über einen öffentlichen Vorschlagsprozess.

Technisch steht mit der Spec-Version 2026-07-28 die größte Überarbeitung seit dem Start an. Der Kern: Das Protokoll wird stateless. Der initialize-Handshake und die Mcp-Session-Id fallen weg, jede Anfrage steht für sich. Klingt nach Kleinkram, ist aber ein Riesending für alle, die Remote-Server betreiben: Kein Sticky-Session-Routing mehr, ein simpler Load Balancer reicht, horizontal skalieren wird trivial. Dazu kommen MCP Apps – interaktive HTML-Oberflächen, die ein Server in einem gesandboxten iframe ausliefert – und eine Tasks-Extension für langlaufende Workflows. Roots, Sampling und Logging werden als veraltet markiert, bleiben dank einer neuen Deprecation-Policy aber mindestens zwölf Monate erhalten.

Für dich als Nutzer von Claude Code ändert das erstmal wenig – deine .mcp.json läuft weiter. Spannend ist es, wenn du eigene Server baust oder betreibst. Und noch eine Abgrenzung, die oft für Verwirrung sorgt: MCP regelt die Verbindung zwischen Agent und Tool. Googles A2A regelt die Kommunikation zwischen Agenten untereinander. Das eine ist USB-C, das andere TCP/IP. Sie konkurrieren nicht, sie ergänzen sich.

Praxis-Tipp: Klein anfangen

Der häufigste Fehler ist, gleich ein Dutzend Server zu konfigurieren. Das überfrachtet den Kontext und macht es Claude schwerer, die richtigen Tools auszuwählen. Zwanzig Server für ein kleines Projekt sind wie mit Kanonen auf Spatzen zu schießen. Starte stattdessen mit ein oder zwei Servern, die dein konkretes Problem lösen. Beobachte, wie Claude sie nutzt, und erweitere erst dann.

So sieht mein Standard-Setup für ein Web-Projekt aus – vier Server, mehr braucht es selten:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/du/projekte/mein-projekt"
      ]
    }
  }
}

Und jetzt kommt der Moment, in dem es Klick macht. Du tippst: „Schau in die Next.js-Doku, erstell mir eine 404-Seite, teste sie im Browser und öffne einen PR.“ Claude verkettet dafür automatisch alle vier Server – Doku über Context7, Datei über Filesystem, Test über Playwright, Pull Request über GitHub. Ohne dass du irgendetwas dazwischen machst. Gratulation, das ist der Punkt, an dem sich die Einrichtung ausgezahlt hat!

Du willst Claude Code richtig beherrschen? Hol dir mein kostenloses Freebie mit 5 CLAUDE.md-Templates, mit denen du Claude von Anfang an den richtigen Kontext gibst – und wenn du tiefer einsteigen willst, schau dir den kompletten Claude Code Kurs an.

Fazit

Ein MCP Server macht aus Claude Code von einem reinen Coding-Assistenten ein Werkzeug, das in deine echte Arbeitsumgebung integriert ist – mit Zugriff auf deine Datenquellen, dein GitHub und deine Datenbank. Das Model Context Protocol sorgt dabei für einen einheitlichen, offenen Standard, sodass du dein Setup einmal baust und überall nutzt. Seit der Übergabe an die Linux Foundation ist es außerdem ein Standard, der niemandem allein gehört – und der bleibt.

FAQ zu MCP Servern