mysql_mcp_server: MySQL-Zugriff für MCP-Clients über eine kontrollierte Schnittstelle

Welches Problem der Server abnimmt und für wen er gedacht ist

Ein Sprachmodell kann eine SQL-Datenbank nur dann sinnvoll erkunden, wenn ihm jemand sagt, welche Tabellen existieren, wie die Spalten heißen und wie Beispieldaten aussehen. Ohne diese Schicht rät das Modell Spaltennamen und produziert Abfragen, die an der Realität scheitern. mysql_mcp_server setzt genau hier an: Er ist ein Model-Context-Protocol-Server, der zwischen einem MCP-Host wie Claude Code oder Claude Desktop und einer MySQL-Instanz vermittelt. Die Zielgruppe sind Entwickler und Analysten, die im Chatfenster Daten prüfen, Schemata verstehen oder Ad-hoc-Abfragen formulieren wollen, ohne sich für jede Frage durch ein Datenbank-Frontend zu klicken. Der Server ist ausdrücklich als Serverkomponente beschrieben, die die Kommunikation zwischen KI-Anwendungen und MySQL-Datenbanken ermöglicht und Datenbankerkundung über eine kontrollierte Schnittstelle strukturierter macht. Das ist die relevante Einschränkung: Es geht nicht um einen vollwertigen SQL-Client, sondern um eine feste, kleine Werkzeugfläche.

Vier Werkzeuge, ein Prompt-Katalog und die Grenze bei Einzelanweisungen

Der Server exponiert die Werkzeuge execute_sql, get_schema_info und get_table_sample, dazu die Ressourcenliste der Tabellen. execute_sql nimmt einen query-String entgegen und unterstützt SELECT, SHOW, DESCRIBE sowie DML. DML-Aufrufe werden laut README mit einem destruktiven Hinweis markiert. get_schema_info liefert Spaltennamen, Typen, Nullability, Standardwerte und Kommentare und akzeptiert einen optionalen table_name. get_table_sample holt eine Stichprobe mit einem limit, das bei 20 gedeckelt ist. Diese Obergrenze ist bewusst gewählt: Sie verhindert, dass ein Modell versehentlich eine große Tabelle in den Kontext zieht. Alle drei Werkzeuge verstehen qualifizierte Namen der Form database.table, unabhängig davon, ob MYSQL_DATABASE gesetzt ist. Für Bezeichner gilt eine enge Regel: nur alphanumerische Zeichen, Unterstriche und $, wobei der Punkt als Trenner zwischen Datenbank und Tabelle erlaubt ist. Das schließt Backticks, Leerzeichen und Sonderzeichen in Tabellennamen aus. Ein weiteres Limit zieht sich durch alle Werkzeuge: Es werden nur einzelne SQL-Anweisungen unterstützt, Mehrfachanweisungen wie USE db; SELECT ... sind nicht möglich. Wer aus einer anderen Datenbank lesen will, muss den Namen voll qualifizieren, statt den Kontext umzuschalten. Neben den Werkzeugen gibt es MCP-Prompts, also geführte mehrstufige Abläufe, die ein Client auf Anforderung startet. In Claude Code erscheinen sie als Slash-Commands der Form /mcp__<server>__<prompt>, in Claude Desktop im Prompt-Menü. Der README-Ausschnitt zeigt den Prompt explore_databa..., also einen Einstieg in die Datenbankerkundung; die vollständige Prompt-Liste ist im vorliegenden Material abgeschnitten und lässt sich daraus nicht rekonstruieren.

Installation und Registrierung beim Client

Die Installation erfolgt per pip install mysql-mcp-server. Für Claude Code nennt das README einen Einzeiler: claude mcp add --transport stdio designcomputer-mysql_mcp_server uvx mysql_mcp_server. Wer Autohand Code CLI nutzt, registriert den Server mit autohand mcp add mysql env MYSQL_HOST=localhost MYSQL_PORT=3306 MYSQL_USER=your_username MYSQL_PASSWORD=your_password MYSQL_DATABASE=your_database uvx mysql_mcp_server, wobei --scope project nach mcp add die Registrierung auf den aktuellen Arbeitsbereich beschränkt. Zusätzlich bietet Smithery einen Installationsweg: npx -y @smithery/cli install designcomputer/mysql-mcp-server --client claude. Neben der lokalen Ausführung existiert eine gehostete Variante, die laut README ohne lokale Einrichtung auskommt. Der Server lädt beim Start automatisch eine .env-Datei über python-dotenv, gelesen aus dem Arbeitsverzeichnis des Prozesses und dessen übergeordneten Verzeichnissen. Das ist praktisch, wenn man den Server selbst aus dem Projektordner startet, und es ist die Quelle eines verbreiteten Fehlers: Claude Code und Claude Desktop starten den Server aus ihrem eigenen Arbeitsverzeichnis, sodass die projekteigene .env nicht gefunden wird und die Meldung Missing required database configuration erscheint. Die dokumentierte Abhilfe ist, die MYSQL_*-Werte direkt im env-Block der MCP-Konfiguration zu hinterlegen. Für entfernte oder selbst gehostete Deployments empfiehlt das README den SSE-Modus, aktiviert über MCP_TRANSPORT=sse, mit MCP_SSE_HOST, PORT als Fallback für MCP_SSE_PORT und MCP_SSE_ALLOWED_HOSTS als kommagetrennte Liste erlaubter Host-Header, standardmäßig localhost:{port},127.0.0.1:{port}.

Sicherheitsrelevante Schalter: SSL, SQL-Modus und SSH-Tunnel

Die Verbindungsdetails stecken vollständig in Umgebungsvariablen. MYSQL_SSL_MODE kennt die Stufen DISABLED, REQUIRED, VERIFY_CA und VERIFY_IDENTITY; der Standardwert ist DISABLED. Wer über ein nicht vertrauenswürdiges Netzwerk arbeitet, sollte das nicht so lassen, denn ohne Verifikation schützt TLS nur gegen passives Mitlesen, nicht gegen einen eingeschobenen Server. MYSQL_CONNECT_TIMEOUT steht standardmäßig auf 10 Sekunden. MYSQL_SQL_MODE setzt den SQL-Modus der Verbindung und ist mit TRADITIONAL vorbelegt, was striktere Typ- und Gruppierungsregeln erzwingt als der MySQL-Standard. Für ältere MySQL-Versionen lässt sich MYSQL_AUTH_PLUGIN auf mysql_native_password setzen, und MYSQL_USE_PURE=false erzwingt den reinen Python-Connector, was relevant ist, wenn die C-Erweiterung auf der Zielplattform nicht gebaut werden kann. MYSQL_RAISE_ON_WARNINGS=false steuert, ob SQL-Warnungen als Fehler behandelt werden. Zeichensatz und Sortierung sind über MYSQL_CHARSET=utf8mb4 und MYSQL_COLLATION=utf8mb4_unicode_ci einstellbar. Für Umgebungen ohne direkten Datenbankzugang existiert ein SSH-Tunnel: MYSQL_SSH_ENABLE=true aktiviert ihn, dazu kommen MYSQL_SSH_HOST, MYSQL_SSH_PORT, MYSQL_SSH_USER, MYSQL_SSH_KEY_PATH sowie MYSQL_SSH_REMOTE_HOST und MYSQL_SSH_REMOTE_PORT aus Sicht des Sprunghosts und MYSQL_LOCAL_PORT als lokaler Port. Ein Hinweis auf die Betriebsrealität: Die Zugangsdaten stehen damit im Klartext in der Client-Konfiguration oder in einer .env-Datei, und der Server selbst bringt keine eigene Authentifizierungsschicht für den MCP-Transport mit. Wer SSE im Netz betreibt, sollte MCP_SSE_ALLOWED_HOSTS nicht auf einen breiten Wert setzen, da die Voreinstellung bewusst auf die Loopback-Adressen beschränkt ist.

Multi-Datenbank-Modus und wo er an Grenzen stößt

Wird MYSQL_DATABASE weggelassen, arbeitet der Server im Multi-Datenbank-Modus. list_resources liefert dann alle Benutzerdatenbanken, Systemdatenbanken werden herausgefiltert. Abfragen müssen voll qualifizierte Tabellennamen verwenden. Das ist konsistent, kostet aber Bequemlichkeit: Jede Abfrage trägt den Datenbanknamen mit, und ein Modell, das diesen Teil vergisst, erhält einen Fehler statt eines stillen Standardkontexts. Zusammen mit der Beschränkung auf Einzelanweisungen ergibt sich ein spürbar engeres Arbeitsschema als in einer interaktiven SQL-Konsole. Ein zweiter Punkt betrifft die Werkzeugfläche selbst. get_table_sample deckelt bei 20 Zeilen, get_schema_info liefert Metadaten nur für eine benannte Tabelle oder für den konfigurierten Kontext, und execute_sql unterscheidet nicht zwischen lesenden und schreibenden Anweisungen, abgesehen von der Markierung. Es gibt im vorliegenden Material keinen Hinweis auf eine Read-only-Option, auf Abfrage-Whitelists oder auf eine Zeilenbegrenzung für execute_sql. Für ein Modell, das eine DELETE-Anweisung ohne WHERE-Klausel formuliert, ist der destruktive Hinweis die einzige Bremse, und ob ein Client ihn als Bestätigungsdialog umsetzt, hängt vom Client ab, nicht vom Server. Das ist eine Designentscheidung, die man beim Lesen des README nicht übersehen sollte: Der Schutz liegt hier bei den Datenbankrechten, nicht im Server.

Alternative: ein generischer MCP-Server mit PostgreSQL oder ein SQL-Toolkit

Die naheliegende Alternative ist ein MCP-Server für eine andere Datenbank, etwa für PostgreSQL, oder ein generisches Datenbank-Toolkit, das der Client direkt aufruft. Der Unterschied liegt weniger im Protokoll als im Umfang der Werkzeuge. mysql_mcp_server bringt genau drei Werkzeuge und eine Ressourcenliste mit, dazu Prompts für geführte Abläufe; ein generisches Toolkit müsste der Client selbst konfigurieren, inklusive Verbindungsaufbau, Fehlerbehandlung und Ausgabeformatierung. Umgekehrt ist die kleine Fläche auch die Einschränkung: Wer Schema-Migrationen, Transaktionen über mehrere Anweisungen oder das Umschalten des Datenbankkontexts braucht, findet dafür im vorliegenden Material keine Werkzeuge. Ein weiterer Unterschied zu einem selbstgebauten Wrapper ist die Transportfrage. mysql_mcp_server unterstützt STDIO und Streamable HTTP (SSE) und lässt sich damit auch entfernt betreiben, während ein lokal verdrahtetes Skript typischerweise an einen Rechner gebunden bleibt. Umgekehrt hat ein eigener Wrapper den Vorteil, dass man Abfragen vorab filtern oder ein reines Lesekonto erzwingen kann, ohne auf eine Serveroption zu warten, die es hier nicht gibt.

Wartung, Versionen und Lizenz

Das Projekt steht unter der MIT-Lizenz, was die Einbettung in eigene Werkzeuge und die Weitergabe erlaubt, solange Copyright-Hinweis und Lizenztext erhalten bleiben. Das ist keine Rechtsberatung, sondern die Einordnung der Lizenzkennung. Der Repository-Status zeigt aktive Pflege: Die letzte Veröffentlichung im vorliegenden Material ist v0.4.4 vom 30. Juli 2026, davor v0.4.3 am selben Tag und v0.4.2 am 20. Juni 2026. Zwei Releases an einem Tag deuten auf schnelle Korrekturen hin, was für die Aktualisierung bedeutet, dass man Versionsnummern im Auge behalten sollte, statt einmal zu installieren und zu vergessen. Der Server wird über pip beziehungsweise uvx bezogen, ein Upgrade ist damit ein Neuinstallationsschritt. Die Konfiguration liegt außerhalb des Pakets in Umgebungsvariablen, sodass ein Versionswechsel keine Konfigurationsmigration erfordert, solange die Variablennamen stabil bleiben. Ein Hinweis auf die Testinfrastruktur: Das README verlinkt eine GitHub-Actions-Workflow-Datei test.yml, was auf automatisierte Tests hindeutet, ohne dass aus dem vorliegenden Material Umfang oder Abdeckung hervorgehen.

Redaktionelles Fazit

Sinnvoll ist mysql_mcp_server für Teams, die einem MCP-Client lesenden Zugriff auf eine MySQL-Instanz geben wollen, ohne eine eigene Werkzeugschicht zu schreiben, und die bereit sind, Zugangsdaten im Konfigurationsblock des Clients zu pflegen. Wer Schreibzugriff auf Produktionsdatenbanken braucht, sollte vorher prüfen, ob ein reines Lesekonto mit entsprechenden GRANTs ausreicht, denn execute_sql führt auch INSERT, UPDATE und DELETE aus und markiert sie lediglich mit einem destruktiven Hinweis. Vor dem Rollout ist zu klären, ob die Zielversion des Clients MCP-Prompts als Slash-Commands darstellt, ob MYSQL_DATABASE gesetzt werden soll oder der Multi-Datenbank-Modus mit ausschließlich qualifizierten Tabellennamen gewünscht ist, und ob die Verbindung über MYSQL_SSL_MODE=VERIFY_IDENTITY abgesichert werden kann.

Offizielle Quellen

1. designcomputer/mysql_mcp_server on GitHub
2. License: MIT
3. Project website
4. README
5. Releases