Ein MCP-Server ist eine Telefonleitung. Entscheidend ist, wer abhebt. Die meisten ABAP-MCP-Server verbinden einen Agenten mit dem SAP-System selbst: Sie lesen Quelltext, legen Objekte an, aktivieren, transportieren. Der Sysparency-MCP-Server verbindet den Agenten mit etwas, das ihm das System nicht sagen kann: dem Gesamtbild des Custom Codes und wie er in die Prozesse des Unternehmens eingreift, mit jeder Abhängigkeit, jedem Nutzungszähler und jeder Geschäftsregel, belegt bis zur Quellzeile. Dieser Artikel zeigt, welche Fragen der Server beantwortet, was ein Agent damit gemacht hat und warum ein Graph diese Fragen mit einem Bruchteil der Token beantwortet.
Zwei Arten von ABAP-MCP-Server
Das Model Context Protocol ist ein offener Standard, mit dem ein Agent Werkzeuge auf einem Server aufruft, egal in welchem Client er läuft: Claude, ChatGPT, Copilot, VS Code, Codex oder ein eigenes Framework. Für SAP gibt es zwei Arten von Server, und ein Agent braucht beide.
Die erste Art spricht mit dem System. SAPs ADT-MCP-Server stellt die ABAP Development Tools bereit: eine Klasse anlegen, Quelltext setzen, aktivieren, Syntax prüfen. Das ist die Hand, die schreibt.
Die zweite Art spricht über das System. Der Sysparency-MCP-Server sitzt auf einem Wissensgraphen, der deterministisch aus einem Export des Custom Codes gebaut wird, und er liest nur. Er weiß, welches Programm welche Tabelle schreibt, welche Transaktion noch benutzt wird, welcher Exit welches Standardobjekt erweitert und was ein Programm fachlich tut. Das ist das Auge, das versteht. Ein Agent mit nur der ersten Art sieht ein Programm nach dem anderen; ein Agent mit beiden sieht das System und verändert es dann.
Was der Graph enthält
Der Graph ist keine Kopie des Quelltexts. Er ist ein Modell des Systems, aus dem Export extrahiert und bei jedem Upload neu erzeugt. Programme, Klassen, Funktionsgruppen und Includes sind Code-Einheiten; Dynpros, Formulare, Transaktionen, CDS-Views, Tabellen und ihre Spalten sind eigene Knoten; Erweiterungen, Customer-Exits, Modifikationen und ATC-Befunde hängen an dem Code, den sie betreffen; Geschäftsprozesse und Module gruppieren alles von oben; Laufzeit-Einstiegspunkte tragen die beobachtete Nutzung. Die Beziehungen sind die Fragen, die Menschen stellen: ruft auf, liest, ändert, selektiert aus, erweitert, implementiert in, beobachtet gestartet, betroffen von.
Der Graph enthält auch, was der Code nicht sagen kann. Bestehende Dokumentation, Spezifikationen und das Wissen der Menschen, die das System betreiben, werden an die Objekte gehängt, die sie beschreiben. Ein Agent findet den Grund für ein Programm damit neben dem Programm selbst. Und jeder Fakt aus dem Code trägt seine Quellzeile, damit der Agent zitieren kann, was er gefunden hat, statt es zu umschreiben.
Was der Agent fragen kann
| Frage | Was der Server liefert | Beispiel |
|---|---|---|
| Was macht dieses Objekt? | Einen Steckbrief in einem Aufruf: fachliche Beschreibung, Modul und Prozesse, Transaktionen, Jobs, Nutzung, gelesene und geschriebene Tabellen, ATC-Befunde und Aufrufbeziehungen. | Was macht ZSD_PRICING, und läuft es noch? |
| Was hängt daran? | Alle direkten und indirekten Aufrufer, Transaktionen, Dynpros, Jobs, Schnittstellen und Erweiterungen. Bei Tabellen und CDS-Views jedes Programm, das liest oder schreibt, mit Fundstelle. | Was ist betroffen, wenn sich die Konditionstabelle ändert? |
| Welche Daten nutzt diese App? | Für eine Fiori-App, ein Dynpro, eine Web-Dynpro-Anwendung oder eine Transaktion: die aufgerufenen Services, die Backend-Klassen, die CDS-Views bis zur Basistabelle und die Tabellen, die gelesen und geschrieben werden. | Welche Tabellen schreibt die Fiori-App für die Auftragserfassung? |
| Passt das zum Standard? | Je Programm die Fakten für die Fit-to-Standard-Bewertung: Funktionen, Nutzung, Datenzugriffe, Kopplung und die verwendeten SAP-Schnittstellen mit ihrer Clean-Core-Stufe. Je Prozess die Übersicht für den Workshop. | Welche Eigenentwicklungen in Order-to-Cash werden genutzt, und welche sind noch offen? |
| Wo wird ein Thema behandelt? | Suche nach Namen oder fachlichem Begriff, in jeder Sprache, über die fachliche Dokumentation, die Sysparency für jedes Programm, jedes Dynpro, jede Tabelle, jede CDS-View und jeden Exit erzeugt hat. | Wo werden Kreditlimits geprüft? |
| Alles andere zu Beziehungen | Lesende Abfragen direkt auf dem Graphen, für Fragen ohne fertige Antwort. | Welche Programme schreiben die Buchungstabelle, und wie oft läuft jedes davon? |
| Was steht genau im Code? | Quelltext und Metadaten aus dem analysierten Stand, mit denselben Zeilennummern wie die Analyse, und eine Suche über den gesamten Custom Code. | Jedes COMMIT WORK innerhalb eines BAdI, gruppiert nach Paket. |
Die häufigen Fragen beantwortet der Server mit einem einzigen Aufruf. Für alles andere fragt der Agent den Graphen frei, und den Quelltext liest er zuletzt, nur dort, wo die genaue Logik entscheidet. Die Tabelle zeigt eine Auswahl, mit jedem Release kommen Werkzeuge dazu.
Warum der Graph Token spart
Eine Frage wie „Welche Programme schreiben die Buchungstabelle, und wie oft?“ wird in der Graphdatenbank beantwortet, nicht vom Sprachmodell. Der Agent schickt eine Abfrage und bekommt ein paar hundert Token Ergebnis zurück: elf Namen, ihre Zugriffsarten, ihre Aufrufzahlen. Ohne den Graphen müsste er hunderte Programme durch das Modell lesen, um dieselben elf zu finden, und die Aufrufzahlen wüsste er dann immer noch nicht. Dasselbe gilt für Nutzung, Abhängigkeiten und fachliche Bedeutung: Das Schließen passiert im Modell, das Auswerten im Graphen. Quelltext kommt erst am Ende in den Kontext, für die Handvoll Programme, auf die es ankommt. Deshalb bleibt eine Analyse über ein ganzes System in einem normalen Kontextfenster und einem normalen Budget.
Was ein Agent damit gemacht hat
Beim Neubau einer 25 Jahre alten Dynpro-Anwendung hatte der Agent zwei Server: Sysparency-MCP-Server zum Verstehen, SAP-ADT-MCP-Server zum Schreiben. Bevor er etwas erzeugt hat, hat er den Graphen gefragt, und drei Antworten haben das Design verändert.
- Elf Anwendungen schreiben die Buchungstabelle, nicht nur die drei Dialogprogramme: eine Funktionsgruppe fügt ein und ändert, eine BAPI-Gruppe ändert, ein ALE-Generator löscht, und 35 RFC-fähige Funktionsbausteine sitzen auf denselben Tabellen. Eine neue App, die nur die Dialoge ersetzt, wäre ein weiterer Schreiber unter vielen gewesen, also wanderten die Regeln in die Business-Objekte.
- Ein Prüfprogramm mit Nutzung 0 reparierte nachts, was die Dialoge nicht validiert hatten. Seine Regeln wurden Validierungen beim Speichern.
- 4 870 Anzeigeaufrufe gegen 158 Änderungen. Die Anwendung wird weit öfter gelesen als geschrieben, also wurde Lesen der Standard und Bearbeiten ein bewusster Schritt.
Nichts davon ist in einem einzelnen Programm sichtbar. Alles davon ist eine Abfrage entfernt.
Back to Standard, mit der SAP-Dokumentation daneben
Der Sysparency-Server kennt das Ist. Er weiß nicht, was der SAP-Standard heute bietet. Wird ein SAP-Dokumentations-MCP-Server daneben angebunden, kann der Agent beide Seiten fragen: Was tut dieses Z-Programm, und gibt es ein freigegebenes Standardobjekt, das dasselbe tut? Wo die Antwort ja lautet, kann die Erweiterung zurück in den Standard; wo sie nein lautet, wird die verbleibende Lücke dokumentiert, mit Belegen auf beiden Seiten. So wird Clean Core eine Entscheidung je Programm statt ein Schlagwort.
Für Fit-to-Standard liefert der Server die Fakten dafür gleich mit, je Programm und je Prozess. Die Standardkandidaten sucht der Agent in der SAP-Dokumentation. Wie er damit tausende Empfehlungen abarbeitet, steht im Artikel Fit-to-Standard mit Custom Code.
Leitplanken
- Nur lesend. Alle Werkzeuge sind als lesend deklariert; schreibende Operationen in einer Abfrage werden abgewiesen, bevor sie die Datenbank erreichen.
- Nur Ihr Code. Der Graph enthält die Kundennamensräume, nie SAP-Standardquelltext. Standardobjekte erscheinen als Referenzen, nicht als Code.
- Eine Umgebung je Kunde. Graph und Server laufen in einer dedizierten Umgebung; der Zugriff läuft über Microsoft Entra ID mit OAuth-Bearer-Tokens, die gegen Ihren Tenant geprüft werden.
- Jeder Client. Der Server spricht Standard-MCP über HTTPS. Der Verbindungsdialog sitzt im Kopf des Reports: URL kopieren, im Client eintragen, fragen.
Was es nicht ist
Es ist kein Codegenerator; dafür gibt es den ADT-Server. Es ist kein Chat über Quelldateien; der Graph wird deterministisch gebaut, derselbe Export ergibt denselben Graphen. Und es ersetzt niemanden, der entscheidet, was geändert wird. Es gibt dem Agenten und dem Menschen, der den Agenten prüft, dieselben Belege für die Entscheidung.
Erste Schritte
- Den Sysparency-Report öffnen und die MCP-URL aus dem Kopf kopieren.
- Im Client als Remote-MCP-Server eintragen und mit dem Firmenkonto anmelden.
- Die erste Frage stellen: „Welche meiner Programme laufen noch und schreiben Tabelle X?" Die Antwort kommt mit Aufrufzahlen und Quellzeilen.
Das Gesamtbild dessen, was ein Agent auf dieser Grundlage kann, steht unter agentisches Re-Engineering. Oder Demo buchen und den Graphen des eigenen Systems fragen.