Joule-Wiki

Open-Source-MCP im SAP-Ökosystem

4 Min. Lesezeit

Open-Source-MCP im SAP-Ökosystem

Parallel zu SAPs eigener agentic-AI-Strategie (Joule for Developers mit dem hauseigenen ABAP MCP Server ab Q2 2026) ist 2025/2026 in der Community eine Open-Source-Bewegung entstanden, die SAP-Tooling-APIs per Model Context Protocol an MCP-fähige Agenten anflanscht — ohne Bindung an AI Units, ohne SAP-Cloud-Vertrag, ohne Modellbindung an den GenAI Hub.

Erstnennung im Wiki über die NextLytics-Blog-Quelle (April 2026).

Was diese Seite macht

Diese Seite beschreibt das Phänomen, nicht jedes einzelne Projekt. Wenn neue Bibliotheken auftauchen, kommen sie hier in die Tabelle — bis sie eigenständige Konzept-Seiten rechtfertigen.

Aktuelle Projekte (Stand April 2026)

ProjektWartungScopeReifeRepo
marianfoo/sap-ai-mcp-serversMarian ZeisKuratierte Liste aller MCP-Server fürs SAP-Ökosystemaktiv gepflegtGitHub
oisee/vibing-steampunkoiseeABAP über ADT-APIin EntwicklungGitHub
dnic-dev/bw-modeling-mcpDavid Nicolay (NextLytics)BW Modeling Tools über BW-Modeling-REST-API„Call for Testers” 04/2026GitHub

Wie das technisch funktioniert

Drei Eigenschaften haben alle drei Projekte gemeinsam:

  1. Lokaler Node.js-Prozess statt Server-Infrastruktur: Trotz „Server” im Namen läuft jedes MCP-Projekt als lokales Skript, das die agentic Umgebung (Claude Code, Codex u.a.) beim Start mit hochzieht. Kein Cloud-Hosting, keine offene Schnittstelle, kein zusätzliches IT-Asset.
  2. Tooling-API als Untergrund: Die Server kapseln interne SAP-Tooling-APIs (ADT-API, BW Modeling REST API), die SAP-eigene Werkzeuge wie Eclipse intern nutzen. Diese APIs sind nicht öffentlich dokumentiert, aber stabil genug, dass eine Reverse-Engineering-Schicht trägt.
  3. Lese- und Schreibebene mit expliziter Bestätigung schreibender Operationen durch den Agenten. Damit kontrolliert der Entwickler, was genau ins System geht.

Was das im Markt bedeutet

  • DSAG-Resonanz: Marian Zeis’ Vortrag auf den DSAG-Technologietagen 2026 in Hamburg sei laut Quelle „proppevoll” gewesen. Open-Source-MCP für SAP ist also kein Nischen-Phänomen mehr, sondern ein DACH-weites Gesprächsthema.
  • Niedrige Eintrittshürde für Kunden: Wer einen API-Key für ein beliebiges LLM hat (Anthropic, OpenAI, lokale Modelle), kann diese Server heute schon ausprobieren. Joule for Developers bleibt zwar bis September 2026 kostenlos, ist aber an SAP-Vertragsstände gebunden.
  • Konkurrenz auf der Modell-Ebene: Open-Source-MCP-Lösungen funktionieren mit jedem MCP-fähigen Client. Der GenAI Hub als zentrale LLM-Routing-Schicht entfällt — und damit fällt für SAP ein wichtiger Differenzierungs- und Governance-Hebel weg.

Wo die Grenzen liegen

  • Reife für Produktion ist projektabhängig. bw-modeling-mcp läuft Stand April 2026 nur gegen NextLytics-Demosysteme — kein Kundeneinsatz dokumentiert.
  • Reverse-engineerte APIs sind nicht offiziell unterstützt: Wenn SAP die interne API ändert, muss der Open-Source-Server nachziehen. Bei Joule trägt SAP diese Wartungslast.
  • Kein Governance-Framework wie der GenAI Hub: Anonymisierung, RAG-Grounding, zentrale Modell-Freigabe, Audit-Logs — alles, was der Hub zentral löst, müsste hier pro Projekt selbst gebaut werden.
  • Compliance-Risiko: Welche Berechtigungen hat der ausführende Entwickler-Account? Wer auditiert die Tool-Aufrufe? Für EU-AI-Act-Compliance ist eine zentrale Logging-Schicht praktisch Pflicht — die hat hier keiner gebaut.

Abgrenzung

  • Open-Source-MCP vs. SAP ABAP MCP Server: SAPs eigene Lösung kommt mit Joule, läuft im SAP-Vertragsstapel und nutzt den GenAI Hub. Open-Source kommt aus der Community, läuft eigenständig, nutzt beliebige LLMs.
  • Open-Source-MCP vs. Joule Studio: Joule Studio baut Agenten/Skills für Business-Szenarien. Die Open-Source-MCP-Server adressieren Entwickler-Szenarien, oft mit anderem Geschmack (Open-Source-Mindset, lokale Tools).
  • Open-Source-MCP vs. Microsoft Copilot for SAP: Beide leben außerhalb von Joule. Copilot ist proprietär und liefert dafür eine integrierte Office-Erfahrung; Open-Source-MCP ist offen, aber „nackt” — Funktion ohne Frontend-Komfort.

Relevanz für ADVIA-Projekte

  • In Joule-Pitches: Damit rechnen, dass Kunden „Wir haben gehört, das geht auch ohne Joule” einbringen — vor allem auf Entwicklerseite. Antwort vorbereiten, die Joule-Stärken (Governance, Hub, Grounding) sauber gegen Open-Source-Stärken (Kosten, Modell-Wahl, Geschwindigkeit) abwägt.
  • In Architektur-Beratung: Mischbetrieb ist möglich — Joule für Business-Agenten, Open-Source-MCP für interne Entwicklungs-Workflows. Aber: nur, wenn Compliance- und Audit-Mechanismen separat gelöst sind.
  • In Hands-on-Beratung: Wenn ein Kunde uns nach einem schnellen Prototyp für agentic AI auf BW oder ABAP fragt, ist bw-modeling-mcp / vibing-steampunk heute schon eine Option — die SAP-eigene Variante wartet noch auf GA. Das gibt uns einen Schnellstart-Pfad.

Offene Fragen

  • Test-Umgebung: Wer in unserem Netzwerk hat ein BW/4HANA-Sandbox, an dem wir bw-modeling-mcp ausprobieren können?
  • Lizenz-Audit: Welche Open-Source-Lizenz haben die drei Projekte? Bevor wir sie Kunden empfehlen, prüfen.
  • SAP-Statement: Gibt es offizielle SAP-Aussagen zur Nutzung reverse-engineerter Tooling-APIs in Kundensystemen? Bei Wartungsverträgen/Support-Statement relevant.
  • Performance & Token: Was kostet eine typische BW-/ABAP-Operation in Tokens? Der NextLytics-Autor stellt diese Frage offen — antworten kommen vermutlich in Folge-Artikeln.

Verwandte Seiten

Quellen

← Konzepte · Inhaltsverzeichnis

Graphansicht

Backlinks