Der marselsel/Lexware-MCP-Server ist ernst zu nehmen: aktive Pflege, Docker, Tests, und als einziger im Feld ein eigener OAuth-Wrapper.
Er bleibt trotzdem ein Selbstbau: Installation, Betrieb und Berechtigungskonzept lasten auf dem Anwender.
Inzwischen konkurrieren sieben Community-Projekte um dieselbe Lücke, alle ohne Mandantenmodell, Idempotenz oder Protokoll.
Der Hersteller bietet API-Key, aber keinen agentengerechten Endpunkt (die Lücke, die die Community siebenfach füllt).
Von allen Community-Projekten in unserem Deutscher MCP-Report 2026 ist der Lexware-MCP-Server (32 Sterne, Stand 22. September 2026) das ausgereifteste Beispiel dafür, was engagierte Nutzer erwarten und was ihnen der Hersteller bisher schuldig bleibt. Wir haben in den Code geschaut.
Was drinsteckt
Das Projekt ist ein TypeScript-MCP-Server mit erstaunlich vollständiger Werkzeugabdeckung für den Alltagsbereich: Kontakte (Liste/Detail/Anlegen/Ändern), Artikel, Belege/Voucher, Datei-Uploads inklusive URL-Upload, Ereignis-Abos, Profil- und Referenzdaten: rund 25 Werkzeuge. Dazu:
- Ein eigenes OAuth-Slice: Der Server kann sich selbst als OAuth-Ressource verhalten (Authorization-Server-Metadata, Token-Prüfung), im Community-Feld fast einmalig, wo sonst statische Keys in Umgebungsvariablen üblich sind.
- Betriebsreife-Signale: Dockerfile, Tests, Security-Policy, Changelog: Die Hygiene stimmt.
- Skybridge-Framework: das Projekt zieht eigene Infrastruktur-Bausteine nach, statt alles selbst zu improvisieren.
Was auch in diesem Server fehlt
Genau die Schicht, die den Unterschied zwischen „läuft bei mir" und „darf ins Produktions-Rechnungswesen" ausmacht:
- Kein Mandanten-/Rechte-Modell über den Key hinaus: Der Lexware-API-Key bleibt ein Alles-oder-nichts-Token; der Server kann ihn nicht einschränken, nur weiterreichen.
- Keine Idempotenz-Schicht bei Schreibaktionen: Ein Agent-Loop, der zweimal feuert, legt zwei Belege an.
- Kein Audit-Protokoll auf MCP-Ebene: was der Agent wann mit welchen Argumenten getan hat, landet in keinem Log.
- Kein OAuth zum Lexware-Produkt selbst: Der OAuth-Wrapper schützt den Server-Zugang, nicht die Delegation im Namen eines Lexware-Nutzers (die Lexware-API bietet dafür schlicht keinen Flow).
Das ist keine Kritik am Projekt: Punkt 1–3 sind exakt die Bausteine, die Arbeit brauchen und die ein Hersteller in sein Produkt investieren müsste. Bis dahin ist der Server die beste verfügbare Option für Leute, die wissen, was sie tun.
Inzwischen ein kleines Ökosystem
Der marselsel-Server ist längst nicht mehr allein. Eine eigene Zählung auf GitHub (Stand 22. September 2026) findet sieben Community-MCP-Server für Lexware Office: den hier betrachteten Selbstbau mit OAuth-Ideen (32★), einen zweiten Self-Hosted-Ansatz (6★), gehostete Varianten, lokale Single-Tenant-Bauten und Experimente. Verzeichnisse wie Glama listen die Projekte, Endkunden finden und installieren sie also längst.
Sieben Projekte bedeuten sieben Mal dieselbe Antwort auf dieselbe Lücke, und sieben Mal ohne die Schicht, die im Rechnungswesen zählt: kein Mandanten-/Rechte-Modell über den Key hinaus, keine Idempotenz, kein Audit-Protokoll, kein echter Delegations-OAuth zum Produkt. Niemand in diesem Feld löst das Problem, jeder dupliziert es.
Die eigentliche Botschaft an Lexware
Das Bild ist eindeutig: Es gibt eine aktive Community, die eure API mit Agenten verbinden will, sieben fertige Projekte mit einem Spitzenreiter über 30 Sternen und einen Markt, in dem awork und seven.io zeigen, wie der offizielle Weg aussieht. Die Kunden bauen die Lücke bereits selbst: inzwischen zum siebten Mal, nur eben ohne Berechtigungskonzept, ohne Protokoll und ohne eure Verantwortung.
Der Schritt vom API-Key zum agentengerechten Endpunkt ist kleiner, als er von außen wirkt. Wir bauen genau diese Endpunkte zum Festpreis und beraten davor, ob sich der Schritt für euer Produkt lohnt: Agent-Readiness-Audit.
Unabhängigkeitshinweis: Wir sind weder mit dem Lexware-MCP-Server-Projekt noch mit Lexware verbunden. Der Code-Blick war eine Momentaufnahme zum Zeitpunkt der Recherche (September 2026).