Ich bekam kürzlich eine Anfrage, die sich vermutlich noch häufiger stellen wird: Kunde hat eine Access-Datenbank, will darüber statistisch auswerten lassen, per Claude Pro, am liebsten ohne dass jemand für jede neue Kennzahl einen eigenen Python-Server pflegt. Die naheliegende erste Antwort — ein handgeschriebener MCP-Server mit einem Tool pro Abfrage — hat genau dieses Problem selbst gebaut. Es gibt inzwischen einen saubereren Weg, und es gibt Fälle, in denen der saubere Weg trotzdem die falsche Wahl ist.
Das Tool-Wildwuchs-Problem
Ein MCP-Server, der pro Kennzahl ein eigenes @mcp.tool() bekommt, funktioniert für eine Handvoll fest definierter Fragen ordentlich. Sobald der Kunde aber anfängt, spontan zu fragen — „Wie verteilen sich die Aufträge nach Monat?“, „Welche zehn Kunden haben den höchsten Umsatz?“, „Gibt es Ausreißer in Tabelle X?“ — reicht das Tool-Set nie. Entweder du schreibst ständig nach, oder der Kunde bekommt nur die Fragen beantwortet, die du vorausgesehen hast. Beides ist auf Dauer unbefriedigend, und beides ist genau das Muster, das ich selbst in einem älteren Artikel zur Access-Claude-Anbindung so aufgebaut hatte: zwei Demo-Tools, jedes mit fest codiertem SQL.
Drei Kategorien von Access-MCP-Servern
Bevor du dich für einen Ansatz entscheidest, lohnt sich eine Sortierung. Auf dem Markt haben sich mittlerweile drei klar unterscheidbare Kategorien herausgebildet:
Automatisierungs-Agenten wie MCP-Access (67 Tools, COM-Automation, ausschließlich Windows) geben dem Modell vollen Zugriff auf VBE, Formulare, Controls und Compile-Vorgänge. Das ist ein Entwickler-Werkzeug für Modernisierung und Refactoring — nicht für Auswertung. Wer damit nur SELECT-Abfragen fahren will, nutzt einen Bagger als Schaufel.
Abfrage-Layer wie mcp-server-access-mdb geben dem Modell einen generischen Zugriff auf Daten: eine Handvoll Tools, die auf beliebige Tabellen und beliebiges SQL anwendbar sind, statt eines Tools pro Kennzahl. Das ist die Kategorie, die zur eingangs beschriebenen Anfrage passt.
Cloud-Gateways wie Query Streams verlagern die Datenbank-Anbindung in einen gehosteten MCP-Endpunkt, erreichbar per URL statt per lokalem stdio-Prozess. Dazu unten mehr im PS, weil das die Antwort auf die Frage „Claude Pro oder Claude Desktop?“ verschiebt.
mcp-server-access-mdb im Detail
scanzy/mcp-server-access-mdb ist ein schlanker Python-Server auf Basis von FastMCP, SQLAlchemy und pandas. Statt für jede Fragestellung ein neues Tool zu schreiben, bekommt Claude ein generisches Set:
connect/disconnect— Datenbankverbindung öffnen und schließen, wahlweise mitreadOnly=truelist— aktive Verbindungen auflistenquery— freies SELECT gegen die verbundene Datenbankupdate— INSERT/UPDATE/DELETE, sofern nicht read-only verbundenimport_csv/export_csv/import_excel— Datenaustauschread_notes/write_notes— menschenlesbare Notizen zu einer Datenbankdatei ablegen, die bei künftigen Sitzungen wieder eingelesen werden
Der entscheidende Unterschied zum Wartungsdemo-Muster: Claude schreibt das SQL selbst, basierend auf dem, was es über das Schema erfährt. Neue Auswertung heißt neue Frage, nicht neues Tool.
Installation
Der Server läuft per stdio, also lokal über Claude Desktop. Eintrag in der claude_desktop_config.json:
{
"mcpServers": {
"access-mdb": {
"command": "uv",
"args": [
"run",
"--with", "fastmcp",
"--with", "pandas",
"--with", "sqlalchemy-access",
"--with", "openpyxl",
"fastmcp", "run",
"C:\\Pfad\\zu\\mcp-server-access-mdb\\server.py"
]
}
}
}
Voraussetzung ist uv als Python-Paketmanager (ersetzt hier pip) sowie eine lokale Kopie des Repos — eine PyPI-Veröffentlichung gibt es noch nicht, das Projekt selbst führt das als offenen Punkt. Nach dem Neustart von Claude Desktop verbindest du dich per connect-Aufruf mit dem Pfad zur .accdb, für reine Auswertung mit readOnly=true. Der Treiber-Zugriff läuft über sqlalchemy-access, technisch also denselben Weg wie ADO/DAO aus VBA, nur von außen.
Risiken, die du vor dem Einsatz kennen solltest
Kein Read-only per Default. Ohne explizites readOnly=true beim connect-Aufruf kann Claude über update schreiben. Bei einer Anfrage, die ausdrücklich nur Auswertung will, gehört die Einschränkung fest in dein Setup-Skript oder in die System-Prompt-Anweisung — nicht in die Hoffnung, dass niemand danach fragt.
Kleines Projekt, kurze Historie. Acht Sterne, ein Maintainer, keine erkennbare Produktionshistorie bei Dritten. Für den eigenen Prototypen oder einen überschaubaren Kunden okay, für einen Kunden mit hoher Verfügbarkeitsanforderung würde ich vorher selbst durch den Code gehen, nicht nur das README lesen.
Kein Audit-Trail. Anders als bei kommerziellen Alternativen gibt es keine eingebaute Protokollierung, wer wann welche Abfrage gefahren hat. Bei sensiblen Daten (Personal, Kalkulation) ist das ein Punkt, den du separat lösen musst, wenn der Kunde danach fragt.
Freies SQL vom Modell heißt: Locking-Verhalten im Blick behalten. Access unterstützt gleichzeitige Lesezugriffe problemlos, auch wenn die Datei parallel in Access geöffnet ist. Bei update-Aufrufen aus dem MCP-Server gilt dasselbe Kollisionsrisiko wie bei jedem externen Schreibzugriff auf eine geöffnete .accdb — nichts Neues für Access-Entwickler, aber leicht zu übersehen, wenn man den MCP-Layer als Blackbox behandelt.
32-Bit-versus-64-Bit-Treiberfalle bleibt bestehen. Wie schon beim Wartungsdemo-Ansatz: Die Architektur von Python und die des installierten Access-ODBC-Treibers müssen zusammenpassen. sqlalchemy-access löst dieses Problem nicht, es liegt eine Ebene tiefer beim Treiber.
Querverweise: Welcher Ansatz wann
| Ansatz | Zweck | Zugriff | Client | Reifegrad |
|---|---|---|---|---|
| Eigener Server (ein Tool pro Abfrage) | Feste, kleine Frageliste | pyodbc, selbst gebaut | Claude Desktop | volle Kontrolle, aber Wartungsaufwand steigt mit jeder neuen Frage |
| mcp-server-access-mdb | Freie Ad-hoc-Auswertung | SQLAlchemy, generisches query/update | Claude Desktop | schlank, jung, ohne Audit-Trail |
| MCP-Access (67 Tools) | VBA/Formulare/Struktur bearbeiten | COM-Automation | Claude Code | produktiv, aber falsches Werkzeug für reine Auswertung |
| Access-MCP (access-mcp.ai) | Auswertung mit Nachvollziehbarkeit | .NET, granulare Tool-Freigabe | mehrere MCP-Clients | kommerziell, Free-Tier read-only, Audit-Trail vorhanden |
| Query Streams | Auswertung ohne lokalen Prozess | gehosteter Endpunkt, SELECT-only erzwungen | claude.ai (Browser) und Desktop | Cloud-Abhängigkeit, dafür browserfähig |
Wo der generische Ansatz an Grenzen stößt
Ein generischer query-Tool ist kein Ersatz für Struktur-Wissen. Claude sieht das Schema so, wie es tatsächlich ist — mit undokumentierten Beziehungen, Feldern, die seit zehn Jahren nicht mehr befüllt werden, und Namen, die nichts über den Inhalt verraten. Wer eine Strukturanalyse vor der Anbindung überspringt, bekommt schneller falsche Joins und falsch interpretierte Kennzahlen als mit einem sauber dokumentierten Schema. Das gilt für jeden der oben genannten Ansätze, nicht nur für diesen.
Übersetzt für alle, die selbst keinen MCP-Server aufsetzen
Wenn du das als Dienstleistung anbietest: Der Unterschied zwischen den Ansätzen entscheidet, wie gut das Angebot skaliert. Ein Tool-pro-Abfrage-Server bedeutet laufenden Pflegeaufwand bei jeder neuen Kundenfrage — abrechenbar, aber begrenzt attraktiv für den Kunden. Ein generischer Abfrage-Layer bedeutet, dass die Ersteinrichtung (Schema-Analyse plus Anbindung) einmalig ist und der Kunde danach selbst neue Fragen stellen kann, ohne dich jedes Mal anzurufen. Das ist das wirtschaftlich interessantere Modell — für dich als weniger Nacharbeit, für den Kunden als schnellere Antworten.
Einschränkung
Ich habe mcp-server-access-mdb noch nicht produktiv bei einem Kunden im Einsatz, nur im eigenen Test. Für ein Projekt mit hoher Verfügbarkeitsanforderung oder sensiblen Daten würde ich aktuell entweder selbst nachbessern (Audit-Logging ergänzen, Read-only fest verdrahten) oder auf eine der kommerziellen Alternativen ausweichen.
PS:
Claude Desktop versus claude.ai, und was Query Streams anders macht: Alle bisher genannten Server (der eigene Wartungsdemo, MCP-Access, mcp-server-access-mdb) laufen per stdio als lokaler Prozess. Das funktioniert ausschließlich mit der Claude-Desktop-App, nicht mit dem Browser-Chat unter claude.ai — auch nicht mit einem Claude-Pro-Abo, wenn der Kunde im Browser arbeitet.
Wer „Claude Pro“ sagt, meint oft das Abo, nicht zwingend die Desktop-App; das lohnt sich vorher zu klären. Für den Browser-Fall braucht es einen remote erreichbaren MCP-Server, der per URL eingebunden wird. Genau da setzt Query Streams an: ein kleiner Windows-Agent läuft lokal beim Kunden, meldet sich ausschließlich ausgehend bei einem Cloud-Endpunkt, und dieser Endpunkt lässt sich per MCP-Key direkt in claude.ai einbinden — ohne Firewall-Freigabe für eingehenden Verkehr. Der Dienst erzwingt SELECT-only auf Netzwerkebene, bevor die Anfrage überhaupt den Jet/ACE-OLEDB-Treiber erreicht, und begrenzt Anfragen standardmäßig auf 60 pro Minute sowie 10 Ausführungen pro Minute. Für Kunden, die im Browser bleiben wollen und keine lokale App-Installation wünschen, ist das aktuell die einzige mir bekannte Option in dieser Kategorie.
Quellen
- scanzy/mcp-server-access-mdb, GitHub-Repository und README: github.com/scanzy/mcp-server-access-mdb
- unmateria/MCP-Access, GitHub-Repository: github.com/unmateria/MCP-Access
- Access-MCP: access-mcp.ai
- Query Streams, Dokumentation zur Access-Anbindung: querystreams.com
- Früherer Beitrag auf sesoft.de: Access-Datenbanken an Claude anbinden
- Früherer Beitrag auf sesoft.de: MCP-Access: Was passiert, wenn Claude Code direkt in deiner Access-Datenbank arbeitet?
Über den Autor
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Entwicklung und Modernisierung von Microsoft-Access-Anwendungen. Sein Schwerpunkt liegt aktuell auf der KI-Anbindung bestehender Access- und SQL-Server-Datenbanken über MCP — pragmatisch bewertet, nicht nach Buzzword. Mehr über Sönke Schäfer
Wenn dich nicht der Code, sondern die Wirtschaftlichkeit interessiert — was eine KI-Anbindung für dein Unternehmen konkret bedeutet, ohne ERP-Wechsel: Künstliche Intelligenz im Mittelstand.
