excel-mcp-server: Excel-Dateien über MCP bearbeiten, ohne Excel zu installieren
A Model Context Protocol server for Excel file manipulation
Auf einen Blick
- Was ist das?
- Ein Python-Server, der Excel-Arbeitsmappen als Werkzeuge für MCP-Clients bereitstellt. Er läuft per stdio lokal oder als HTTP-Dienst für entfernte Aufrufe, mit einer Pfadbeschränkung, die man vor dem Produktiveinsatz verstehen sollte.
- Für wen ist es gedacht?
- Wer Excel-Dateien aus einem MCP-Client heraus lesen und schreiben will und keinen Excel-Interpreter auf dem Zielsystem hat, findet hier einen kleinen, MIT-lizenzierten Baustein. Wer Formeln berechnen, Pivot-Tabellen aktualisieren oder mit Makros arbeiten muss, sollte zuerst prüfen, ob die Bibliothek hinter dem Server das leistet, statt sich auf die Werkzeugliste zu verlassen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 157 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem der Server löst und für wen er gedacht ist
Der Auslöser ist eine Umgebungsbedingung, nicht ein Funktionswunsch. Wer einem Sprachmodell Zugriff auf Tabellen geben will, stößt regelmäßig auf dieselbe Wand: Auf dem Rechner oder Container, in dem der Agent läuft, ist kein Microsoft Excel installiert, und ohne Excel gibt es keine COM-Schnittstelle, über die sich Arbeitsmappen öffnen ließen. Der Server umgeht das, indem er Excel-Dateien direkt liest und schreibt. Das README formuliert die Zielsetzung knapp: Excel-Dateien bearbeiten, ohne dass Microsoft Excel installiert sein muss.
Angesprochen sind damit zwei Gruppen. Erstens Entwickler, die einen MCP-fähigen Client wie einen Editor oder einen Chat-Agenten mit Dateizugriff ausstatten und die Rechenarbeit beim Anbieter des Modells lassen wollen. Zweitens Betreiber, die den Server als entfernten Dienst betreiben, damit mehrere Clients auf denselben Dateibestand zugreifen. Für beide Gruppen ist die entscheidende Frage nicht, ob der Server eine Zelle schreiben kann, sondern wie er begrenzt, welche Dateien er überhaupt anfassen darf. Dazu weiter unten mehr, denn genau dort liegt die interessanteste Designentscheidung.
Drei Transportwege, zwei davon mit unterschiedlichem Dateizugriff
Der Server kennt drei Betriebsarten, und sie unterscheiden sich nicht nur im Protokoll, sondern in der Frage, wer den Pfad bestimmt. Beim stdio-Transport startet der Client den Prozess und übergibt bei jedem Werkzeugaufruf den Dateipfad mit. Der Server selbst braucht keine Pfadvariable. Beim SSE- und beim Streamable-HTTP-Transport läuft der Server eigenständig, und hier muss laut README die Umgebungsvariable EXCEL_FILES_PATH auf der Serverseite gesetzt werden. Sie legt fest, wo gelesen und geschrieben wird. Fehlt sie, fällt der Server auf ./excel_files zurück.
Der wichtigere Teil steht in einem Nebensatz: Bei diesen beiden Transportarten müssen die filepath-Werte relativ zu diesem Verzeichnis angegeben werden, etwa reports/q1.xlsx. Absolute Pfade und Verzeichnisdurchquerung werden zurückgewiesen. Das ist eine Sandbox, und sie ist der Grund, warum der Server überhaupt als Netzwerkdienst vertretbar ist. Wer ihn hinter einem Reverse Proxy betreibt, sollte trotzdem bedenken, dass die Grenze nur das Dateisystem betrifft. Es gibt im vorliegenden Material keinen Hinweis auf Authentifizierung oder Zugriffskontrolle auf HTTP-Ebene. Ein offen erreichbarer Streamable-HTTP-Endpunkt ist damit ein offener Schreibzugriff auf alles unterhalb von EXCEL_FILES_PATH.
SSE ist als veraltet markiert, nicht entfernt
Das README führt SSE ausdrücklich als deprecated und empfiehlt Streamable HTTP für entfernte Verbindungen. Der Endpunkt liegt dann unter http://localhost:8000/mcp, während SSE unter /sse lauscht. Beide Wege existieren weiter, was für Bestandsinstallationen praktisch ist und für Neuinstallationen eine klare Vorgabe ergibt: Streamable HTTP. Wer heute eine neue Anbindung baut, hat keinen Grund, den als veraltet gekennzeichneten Pfad zu wählen. Dass beide Varianten dieselbe Pfadbeschränkung teilen, ist eine gute Nachricht, denn es bedeutet, dass ein späterer Wechsel des Transports die Sicherheitsannahmen nicht verschiebt.
Installation und Konfiguration in der Praxis
Der Server wird über uvx gestartet, ohne vorherige Installation in ein Projektverzeichnis. Für den lokalen Betrieb lautet der Befehl uvx excel-mcp-server stdio. Die passende Client-Konfiguration ist ein JSON-Block mit command uvx und args ["excel-mcp-server", "stdio"]. Für den entfernten Betrieb startet uvx excel-mcp-server streamable-http den Dienst, und der Client trägt unter url den Wert http://localhost:8000/mcp ein.
Zwei Umgebungsvariablen steuern den HTTP-Betrieb. EXCEL_FILES_PATH legt das Wurzelverzeichnis fest, FASTMCP_PORT den Port, wobei das README als Standard 8017 nennt und die Beispielkonfiguration 8007 verwendet. Die Beispiele im README setzen beide Variablen vor dem Start, unter Windows in PowerShell, unter Linux und macOS als Präfix vor dem Befehl. Wer den Port nicht setzt, sollte also nicht 8000 erwarten, nur weil die Beispiel-URL das nahelegt. Das ist eine kleine Inkonsistenz in der Dokumentation, die beim ersten Verbindungsversuch Zeit kostet.
Der stdio-Pfad ist der einfachere Einstieg, weil er keine Pfadkonfiguration erfordert und der Server im Prozessbaum des Clients lebt. Er ist aber auch der unflexiblere, sobald mehrere Clients auf denselben Dateibestand zugreifen sollen.
Was die Werkzeugliste verspricht und was das Material belegt
Die Feature-Liste ist lang: Arbeitsmappen und Arbeitsblätter anlegen, lesen und ändern, Formeln, Formatierung, Diagramme, Pivot-Tabellen, Excel-Tabellen, Datenvalidierung, bedingte Formatierung, Blattoperationen wie Kopieren, Umbenennen und Löschen. Die vollständige Dokumentation der Werkzeuge liegt laut README in der Datei TOOLS.md im Repository, die im vorliegenden Auszug nicht enthalten ist.
Das ist die zentrale Einschränkung für jede Bewertung. Aus dem README allein lässt sich nicht ableiten, welche Diagrammtypen tatsächlich unterstützt werden, wie sich Pivot-Tabellen verhalten, wenn sich die Quelldaten ändern, oder ob Formeln nur geschrieben oder auch ausgewertet werden. Die Formulierung create dynamic pivot tables ist eine Selbstbeschreibung des Projekts, kein belegtes Verhalten. Wer den Server für Berichte einsetzen will, die auf Formelergebnissen aufbauen, muss diesen Punkt vorher klären. Ein Server, der eine Formel in die Zelle schreibt, ohne sie zu berechnen, liefert einem Sprachmodell einen anderen Wert als der, den ein Mensch in Excel sieht.
Wann der Server das falsche Werkzeug ist
Drei Fälle sprechen gegen den Einsatz. Erstens, wenn die Arbeitsmappe bereits berechnete Werte benötigt: Ohne Excel als Rechenmaschine hängt alles davon ab, ob die verwendete Bibliothek Formeln auswertet. Das README klärt das nicht, und dieser Punkt entscheidet über die Brauchbarkeit für Auswertungen.
Zweitens, wenn Makros, VBA oder komplexe Arbeitsmappen mit Verknüpfungen zu externen Dateien im Spiel sind. Nichts im Material deutet darauf hin, dass der Server solche Dateien sinnvoll verarbeitet.
Drittens, wenn mehrere Prozesse gleichzeitig in dieselbe Datei schreiben. Das README beschreibt keine Sperrmechanik und keine Konfliktauflösung. Bei einem HTTP-Dienst mit mehreren Clients ist das ein realistisches Szenario, und die Pfadbeschränkung verhindert es nicht. Wer den Server als geteilten Dienst betreibt, sollte die Schreibzugriffe selbst serialisieren, etwa über getrennte Verzeichnisse pro Client unterhalb von EXCEL_FILES_PATH.
Ein vierter Punkt ist eher eine Erwartungskorrektur: Der Server ist ein Werkzeugkasten für einen Agenten, keine Tabellenkalkulation. Aufgaben, die Zwischenergebnisse in Zellen erfordern, verlagern die Rechenlogik in das Modell, und dort ist sie schlechter nachvollziehbar als in einer Formel.
Alternative: direkt gegen openpyxl programmieren
Der naheliegende Vergleich ist die Bibliothek, auf der ein solcher Server typischerweise aufsetzt. openpyxl ist eine Python-Bibliothek zum Lesen und Schreiben von xlsx-Dateien, ohne Excel zu benötigen. Der Unterschied liegt nicht im Funktionsumfang, sondern im Aufrufweg. Mit openpyxl schreibt man Python-Code, der eine konkrete Arbeitsmappe öffnet, Zellen adressiert und speichert. Der Ablauf ist deterministisch, versionierbar und testbar.
Der MCP-Server setzt eine Ebene darüber: Er verwandelt dieselben Operationen in Werkzeuge, die ein Sprachmodell auswählt und mit Argumenten füllt. Das ist dann sinnvoll, wenn die auszuführende Operation erst zur Laufzeit aus einer natürlichen Spracheingabe entsteht. Wenn der Ablauf dagegen feststeht, etwa ein monatlicher Bericht aus derselben Vorlage, ist ein Skript die bessere Wahl. Es kostet keine Modellaufrufe, es scheitert reproduzierbar, und es braucht keinen laufenden Dienst. Der Server lohnt sich für den explorativen Teil der Arbeit, nicht für den wiederkehrenden.
Wartung, Versionierung und Lizenz
Die letzten Veröffentlichungen liegen bei v0.1.6 und v0.1.7 im August 2025 sowie v0.1.8 im April 2026. Die Versionsnummer steht weiterhin bei 0.1.x, was auf eine junge API hindeutet. Wer den Server in eine bestehende Umgebung einbindet, sollte damit rechnen, dass sich Werkzeugnamen oder Argumente zwischen Minor-Versionen verschieben können. Ein Blick in die Release Notes vor jedem Upgrade ist deshalb sinnvoll, nicht optional.
Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange der Urheberrechtshinweis und der Lizenztext beibehalten werden. Für Betreiber entfernte Dienste ist relevant, dass MIT keine Copyleft-Pflichten auslöst. Das ist eine allgemeine Einordnung, keine Rechtsberatung. Wer den Server verändert und weitergibt, muss die Lizenzdatei mitliefern.
Die Installation über uvx lädt Pakete aus PyPI zur Laufzeit. In Umgebungen mit kontrolliertem Paketbezug ist das ein Punkt, der vorab geklärt werden muss, weil uvx nicht das übliche Installationsverfahren einer Organisation ist.
Redaktionelles Fazit
Wer Excel-Dateien aus einem MCP-Client heraus lesen und schreiben will und keinen Excel-Interpreter auf dem Zielsystem hat, findet hier einen kleinen, MIT-lizenzierten Baustein. Wer Formeln berechnen, Pivot-Tabellen aktualisieren oder mit Makros arbeiten muss, sollte zuerst prüfen, ob die Bibliothek hinter dem Server das leistet, statt sich auf die Werkzeugliste zu verlassen. Vor dem ersten produktiven Aufruf: EXCEL_FILES_PATH auf ein dediziertes Verzeichnis setzen, die Tool-Dokumentation in TOOLS.md gegen die eigene Arbeitsmappe durchgehen und einen Schreibzugriff auf eine Kopie testen.
Community-Notizen