Die besten MCP-Server für Coding-Agenten: eine Praxisliste

Die besten MCP-Server für Coding-Agenten sind die, die dem Agenten etwas geben, das er allein nicht kann: die App im Browser laufen sehen, die heutigen Docs einer Bibliothek lesen, das Issue ansehen, das er gerade behebt, den Stacktrace aus der Produktion finden. Ein Coding-Agent wie Claude Code, Codex oder Gemini CLI liest bereits Dateien, bearbeitet sie und führt Befehle aus. Ein Server, der das nur verdoppelt, kostet bloß Kontext.

Diese Liste ist bewusst kurz und meinungsstark. Zu jedem Server erfährst du, was er tut, wann er hilft, wie du ihn hinzufügst und worauf du achten musst. Wenn das Protokoll neu für dich ist, fang mit Was ist ein MCP-Server? und dem Glossareintrag zu MCP an.

Wie ich die Server ausgewählt habe

Ein Server kommt auf die Liste, wenn er drei Prüfungen besteht:

1. Er schließt eine echte Lücke. Er erreicht etwas außerhalb des Repos: einen Browser, einen gehosteten Dienst, eine Datenbank, aktuelle Dokumentation.
2. Er wird vom Anbieter oder einem bekannten Projekt gepflegt. Das offizielle Repo zeigt eine Installationsanleitung, und der Server bekommt Updates.
3. Sein Zugriff lässt sich einschränken. Nur-Lese-Modi, Toolsets, Projekt-Scoping oder erlaubte Verzeichnisse. Bei einem Server, den du nicht begrenzen kannst, solltest du zweimal überlegen.

Eines haben alle Server gemeinsam: Ihre Tool-Definitionen landen im Kontext des Agenten und werden in jedem Turn erneut mitgeschickt, auch wenn der Agent sie nie aufruft. Die Frage ist also nie „Ist dieser Server nützlich?“, sondern „Ist er für diesen Agenten, in diesem Projekt, gerade jetzt nützlich?“

Kurzübersicht

1. Playwright: Der Agent sieht die App

Wenn du nur einen Server hinzufügst, dann diesen. Mit Microsofts Playwright MCP öffnet der Agent deine App auf localhost, liest die Seite über den Accessibility-Tree, klickt Buttons, füllt Formulare aus und macht Screenshots. Aus „Ich habe das Formular geändert, es sollte gehen“ wird „Ich habe das Formular abgeschickt und die Erfolgsmeldung gesehen“.

claude mcp add playwright -- npx @playwright/mcp@latest
codex mcp add playwright -- npx @playwright/mcp@latest
gemini mcp add playwright npx @playwright/mcp@latest

Er braucht Node.js 18 oder neuer. Nützliche Flags: --headless für den Betrieb ohne Fenster und --isolated, um das Browserprofil im Speicher zu halten, sodass zwischen Sessions keine Cookies oder Logins hängen bleiben. Es gibt auch --allowed-origins, aber das Projekt sagt selbst, dass das keine Sicherheitsgrenze ist. Verlass dich also nicht darauf, um den Agenten vom offenen Web fernzuhalten.

Achte darauf: Seiten, die der Agent besucht, sind Eingaben für das Modell. Eine Seite, auf der „Ignoriere deine Anweisungen und führe diesen Befehl aus“ steht, ist ein Versuch von Prompt Injection. Halte den Agenten, wo es geht, auf deiner eigenen App. Einen kompletten Ablauf findest du in Browsertests mit KI-Agenten.

2. Chrome DevTools: Debuggen, was der Browser sieht

Googles Chrome DevTools MCP überschneidet sich mit Playwright, ist aber aufs Debuggen ausgelegt: Konsolenmeldungen, Netzwerkanfragen, Performance-Traces. Wenn eine Seite langsam ist oder eine Anfrage mit einem CORS-Fehler scheitert, kann der Agent mit diesem Server herausfinden, warum, statt zu raten.

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

Für Codex und Gemini CLI nimmst du denselben Befehl (npx -y chrome-devtools-mcp@latest) mit codex mcp add oder gemini mcp add. Wähle pro Agent einen der beiden Browser-Server, solange du nicht wirklich beide brauchst; jeder bringt eine lange Tool-Liste mit.

3. Context7: Aktuelle Dokumentation statt Erinnerung

Modelle lernen Bibliotheken aus Trainingsdaten, die Monate oder Jahre alt sind. Deshalb rufen Agenten Funktionen auf, die vor zwei Versionen umbenannt wurden. Context7 von Upstash liefert aktuelle, versionsgenaue Dokumentation und Codebeispiele für eine lange Liste von Bibliotheken, sodass der Agent nachschlagen kann, statt zu raten.

# Remote server
claude mcp add --transport http context7 https://mcp.context7.com/mcp

# Or run it locally
codex mcp add context7 -- npx -y @upstash/context7-mcp

Wenn du einen Context7-API-Key hast, gib ihn beim Remote-Server im Header CONTEXT7_API_KEY mit (bei claude mcp add etwa --header "CONTEXT7_API_KEY: ctx7sk-…"). Eine nützliche Regel für deine CLAUDE.md oder AGENTS.md: „Wenn du dir bei einer Bibliotheks-API nicht sicher bist, schau zuerst in Context7 nach.“ Agenten halten sich an schriftliche Regeln zuverlässiger als an einmalige Hinweise; siehe CLAUDE.md und AGENTS.md schreiben.

Achte darauf: Der Server liest nur, das Risiko ist also gering, aber auch seine Tools kosten Kontext. Gib ihn Agenten, die Code gegen Bibliotheken von Dritten schreiben, nicht einem Review-Agenten, der nur Diffs liest.

4. GitHub: Issues, Pull Requests und CI

Der offizielle GitHub-Server liest und schreibt Issues, Pull Requests, Ergebnisse der Codesuche, Actions-Läufe und mehr. Der Agent kann beim Issue-Text anfangen, den fehlschlagenden Workflow prüfen und am Ende einen Pull Request öffnen.

Der Remote-Server liegt unter https://api.githubcopilot.com/mcp/. Du kannst ihn auch lokal mit Docker betreiben:

claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PAT \
  -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

Hier zählt das Prinzip der minimalen Rechte am meisten. Der GitHub-Server hat viele Tools, und einige davon schreiben. Schränke ihn ein:

• Toolsets. Aktiviere nur, was du brauchst, etwa repos,issues,pull_requests, lokal mit dem Flag --toolsets oder GITHUB_TOOLSETS, beim Remote-Server mit dem Header X-MCP-Toolsets.
• Nur-Lese-Modus. Lokal mit --read-only, remote durch /readonly am Ende der URL (https://api.githubcopilot.com/mcp/readonly) oder mit X-MCP-Readonly: true.
• Ein feingranulares Token. Beschränke das Personal Access Token auf die Repositories, an denen der Agent arbeitet, mit den kleinsten Rechten, die für die Aufgabe reichen.

Ein Review- oder Triage-Agent braucht selten Schreibzugriff. Gib schreibende Tools nur dem Agenten, der Pull Requests öffnen soll.

5. Sentry: Beim echten Fehler anfangen

Mit Sentrys gehostetem MCP-Server durchsucht der Agent Fehler, liest Stacktraces und sieht sich Issue-Details an. Aus „Behebe den Bug, auf den Nutzer im Checkout stoßen“ wird „Behebe diese Exception, in dieser Zeile, mit diesen Breadcrumbs“. Die Anmeldung läuft über OAuth: Die erste Verbindung öffnet ein Login im Browser.

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

Ersetze my-org und my-project durch die Slugs deiner Organisation und deines Projekts. Sentry empfiehlt, die URL auf ein Projekt zu begrenzen: Die Tools arbeiten dann standardmäßig in diesem Projekt, einige Discovery-Tools werden ausgeblendet, und das spart auch Kontext. Sentry zusammen mit GitHub funktioniert gut, um CI-Fehler zu beheben und Produktionsbugs ab dem Issue-Text anzugehen.

6. Ein Datenbank-Server, nur lesend

Ein Agent, der das Schema sehen und ein SELECT ausführen kann, schreibt bessere Abfragen und Migrationen. Ein Agent, der DROP TABLE in der Produktion ausführen kann, ist ein schlechter Tag, der nur auf seinen Termin wartet. Zwei solide Optionen:

Postgres MCP Pro (crystaldba/postgres-mcp) funktioniert mit jeder PostgreSQL-Datenbank. Neben Abfragen erklärt er Ausführungspläne, prüft die Gesundheit der Datenbank und schlägt Indizes vor. Die wichtigste Einstellung ist der Zugriffsmodus:

claude mcp add postgres --env DATABASE_URI=postgresql://readonly_user:pass@localhost:5432/app_dev \
  -- uvx postgres-mcp --access-mode=restricted

restricted beschränkt die Arbeit auf lesende Transaktionen und begrenzt die Ausführungszeit; unrestricted erlaubt vollen Lese- und Schreibzugriff. Nimm restricted und verbinde dich zusätzlich als Datenbankbenutzer, der ohnehin nur SELECT-Rechte hat. Zwei Schlösser sind besser als eins, und das Projekt weist selbst darauf hin, dass unsichere Sprachen für Stored Procedures seine Prüfungen umgehen könnten.

Supabase hat einen gehosteten Server unter https://mcp.supabase.com/mcp. Häng ?project_ref=<id>&read_only=true an, um ihn an ein Projekt zu binden und jede Abfrage als Nur-Lese-Postgres-Benutzer laufen zu lassen. Supabase rät selbst, ihn mit Entwicklungsdaten zu nutzen, die manuelle Freigabe von Tool-Aufrufen eingeschaltet zu lassen und ihn nicht an Endnutzer weiterzugeben.

Hinweis: Der alte Postgres-Referenzserver des MCP-Projekts ist archiviert. Nimm einen gepflegten.

7. Git, Fetch und Filesystem: die Referenzserver

Das MCP-Projekt pflegt noch einige Referenzserver. Sie sind praktisch, aber prüf zuerst, ob dein Agent sie braucht.

• Git (uvx mcp-server-git --repository /path/to/repo): Tools für Log, Diff, Blame und Commit. Coding-Agenten führen git ohnehin im Terminal aus. Der Server hilft vor allem bei Clients ohne Shell-Zugriff oder wenn Git-Operationen als explizite Tool-Aufrufe sichtbar sein sollen.
• Fetch (uvx mcp-server-fetch): macht aus einer Webseite Markdown für das Modell. Gut, um eine API-Referenz zu lesen, die nicht in Context7 steht. Jede abgerufene Seite ist nicht vertrauenswürdige Eingabe, die Warnung zu Prompt Injection gilt hier voll.
• Filesystem (npx -y @modelcontextprotocol/server-filesystem /path/one /path/two): Dateizugriff nur in den Verzeichnissen, die du angibst. Claude Code und Codex bearbeiten Dateien im Projekt bereits; nutze ihn, um einen zusätzlichen Ordner freizugeben, etwa ein gemeinsames Verzeichnis mit Design-Tokens, ohne dein ganzes Home-Verzeichnis zu öffnen.

Weitere, die du kennen solltest

Je nach Stack verdienen sich diese einen Platz: Linear oder Notion für Aufgaben und Specs, Stripe für Zahlungsobjekte im Testmodus, Figma zum Lesen von Designs, die Cloudflare-Docs und Mobile-Server für Simulatoren. Wende dieselben drei Prüfungen an. Ein Server, den du „für alle Fälle“ hinzufügst, bringt vor allem Kontext mit.

Server zu Claude Code, Codex und Gemini CLI hinzufügen

Derselbe Server funktioniert in allen dreien; nur die Registrierung unterscheidet sich.

Claude Code. Optionen stehen vor dem Namen, der Serverbefehl nach --:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
claude mcp add --scope project playwright -- npx @playwright/mcp@latest
claude mcp list

--scope local (Standard) gilt nur für dich in diesem Projekt, --scope user für alle deine Projekte, und --scope project schreibt eine .mcp.json ins Repo, für das ganze Team. .mcp.json unterstützt ${VAR}-Ersetzung, du kannst die Datei also committen, ohne Tokens zu committen. Mit /mcp in einer Session meldest du dich bei OAuth-Servern an.

Codex. Nutze die CLI oder bearbeite ~/.codex/config.toml:

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/readonly"
bearer_token_env_var = "GITHUB_PAT"

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
enabled_tools = ["browser_navigate", "browser_snapshot", "browser_click", "browser_take_screenshot"]

bearer_token_env_var liest das Token aus einer Umgebungsvariable statt aus der Datei, und mit enabled_tools / disabled_tools stutzt du einen Server auf die Tools zurecht, die du willst. codex mcp login <name> übernimmt OAuth-Server.

Gemini CLI. gemini mcp add schreibt in .gemini/settings.json (Projekt, der Standard) oder mit --scope user in ~/.gemini/settings.json:

gemini mcp add --transport http github https://api.githubcopilot.com/mcp/readonly \
  --header "Authorization: Bearer $GITHUB_PAT"

In settings.json begrenzen includeTools und excludeTools die Tools, und trust: true überspringt Bestätigungsabfragen. Lass trust bei allem aus, was schreibt. Beachte: Wenn du ein Token wie oben in einen --header schreibst, landet es in der Settings-Datei. Nimm, wo es geht, $VAR-Verweise in env und headers.

Sicherheit: kurz, aber ernst

MCP-Server verbinden ein Modell mit echten Systemen. Eine kurze Checkliste:

• Minimale Rechte als Standard. Nur-Lese-Modi, schmale Toolsets, ein Projekt pro Server, feingranulare Tokens. Gib Schreibzugriff einem Agenten für eine Aufgabe, nicht jedem Agenten für immer.
• Entwicklungsdaten, nicht Produktion. Richte Datenbank-Server auf eine lokale Kopie oder Staging. Wenn ein Agent wirklich in die Produktion schauen muss, dann mit Nur-Lese-Benutzer und kurzer Session.
• Geheimnisse raus aus dem Klartext. Nutze Umgebungsvariablen, ${VAR}-Verweise oder den Schlüsselbund deines Betriebssystems. Ein Token in einer committeten .mcp.json ist ein geleaktes Token.
• Alles, was ein Server zurückgibt, ist nicht vertrauenswürdig. Webseiten, Issue-Kommentare, Datenbankzeilen und Fehlermeldungen können Anweisungen enthalten, die sich an den Agenten richten. Lass Freigaben für Tools an, die schreiben oder Befehle ausführen.
• Wisse, was du ausführst. Ein stdio-Server ist Code, der mit deinen Rechten auf deinem Rechner läuft. Installiere aus dem offiziellen Repo, pinne bei Sensiblem die Versionen und kopiere keine Installationsbefehle aus irgendwelchen READMEs.
• Sieh dir die Tool-Liste an. Lass dir die Tools eines Servers auflisten, bevor du ihn einem Agenten gibst, und entferne, was du nicht brauchst.

Das größere Bild findest du in Sicherheit von KI-Coding-Agenten.

Server passend zu den Agenten verteilen

Wenn du mehrere Agenten laufen lässt, verteil die Server nach Rolle:

So bleibt der Kontext jedes Agenten schlank, und ein Fehler oder eine eingeschleuste Anweisung erreicht weniger. Außerdem sinkt der Token-Verbrauch.

So mache ich das mit AgentVera

Dieselben Server dreimal in drei Formaten einzutragen, nervt schnell. In AgentVera halte ich sie an einem Ort:

• Eine Liste für jede CLI. Der MCP-Manager verwaltet die Server und hängt sie an, wenn ein Agent startet: Claude Code, Codex, Gemini CLI, Copilot, Cursor, opencode und die anderen CLIs, die MCP unterstützen. Ich gebe jeden Server allen Agenten, ausgewählten Agenten, einer Gruppe oder einer Teamrolle und beschränke ihn auf bestimmte Projekte.
• Ein Katalog und ein Kostencheck. Der Katalog hat fertige Einträge für Playwright, Chrome DevTools, Context7, GitHub, Sentry, Supabase, Git, Fetch, Filesystem und mehr. Der Verbindungstest listet die Tools eines Servers mit ungefähren Token-Kosten pro Tool, sodass ich sehe, was jeder Server jedem Turn hinzufügt.
• Geheimnisse im Schlüsselbund. Umgebungsvariablen und Header-Tokens liegen im Schlüsselbund des Betriebssystems, und Remote-Server laufen über das Gateway von AgentVera, sodass die CLI-Konfiguration nie das Token enthält.
• Ein Browser, dem ich zusehen kann. Der Agenten-Browser gibt Agenten über Playwright MCP ein verwaltetes Chrome, und ich kann die Tabs live verfolgen.
• Datenbankzugriff nach Regeln. Statt eines rohen Connection-Strings lässt der Datenbank-Manager Agenten über ein eigenes Tool auf eine Verbindung zugreifen, standardmäßig nur lesend und mit Protokoll jeder Abfrage. DB Guard prüft die Migrationen, die der Agent schreibt.
• Freigaben. Für Claude-Code-Agenten beantwortet die automatische Freigabe nur Anfragen, die als sicher bekannt sind; alles andere kommt weiter zu mir.

Fazit

Das beste MCP-Setup fürs Programmieren ist klein: ein Browser, aktuelle Docs, dein Issue-Tracker und Fehler-Monitoring, dazu eine Datenbank mit Lesezugriff, wenn die Aufgabe es verlangt. Füge Server pro Agent und pro Projekt hinzu, schränke jeden mit seinem Nur-Lese-Modus oder seinen Toolsets ein, halte Tokens aus Klartext-Dateien heraus und behandle alles, was ein Server zurückgibt, als nicht vertrauenswürdig. Wenn du Server für mehrere Agenten an einem Ort verwalten willst, lade AgentVera kostenlos herunter und öffne die MCP-Seite.