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, mit jeder Abhängigkeit, jedem Nutzungszähler und jeder Geschäftsregel, belegt bis zur Quellzeile. Dieser Artikel nennt die sieben Werkzeuge, die Fragen, die jedes beantwortet, und was ein Agent damit gemacht hat.
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 mit 26 Knotentypen und 57 Beziehungstypen, 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.
Jeder Fakt trägt seine Quellzeile, damit ein Agent zitieren kann, was er gefunden hat, statt es zu umschreiben.
Die sieben Werkzeuge
| Werkzeug | Was der Agent fragt | Beispiel |
|---|---|---|
| get_neo4j_schema | Was weiß der Graph, und unter welchen Namen? | Wird zuerst aufgerufen, damit eine Abfrage echte Labels und Eigenschaften nutzt statt Vermutungen. |
| read_neo4j_cypher | Jede Frage zu Beziehungen, als lesende Graphabfrage. | Welche Programme schreiben die Buchungstabelle, und wie oft läuft jedes davon? |
| search_functional_documentation | Wo wird ein fachlicher Begriff behandelt, ohne einen Z-Namen zu kennen? | Wo werden Kreditlimits geprüft? Liefert Dynpros, Tabellen, Exits und Programme über ihre fachliche Beschreibung. |
| list_abap_objects | Was existiert, nach Typ, Paket oder Namensmuster? | Alle Funktionsbausteine im Paket ZSD, die mit Z_PRICING beginnen. |
| read_abap_metadata | Was wurde definiert oder erweitert, das der Code allein nicht zeigt? | Bei einer BAdI-Implementierung: der Standard-Erweiterungspunkt und die implementierende Klasse. Bei einer Tabelle: die DDIC-Felder und Typen. |
| read_abap_source | Was tut der Code genau? | Das SELECT, der fest kodierte Wert, die Bedingung in Zeile 112. |
| search_abap_source | Wo kommt ein Muster im gesamten Custom Code vor? | Jedes COMMIT WORK innerhalb eines BAdI, gruppiert nach Paket. |
Die Reihenfolge ist wichtig. Ein guter Agent beginnt mit dem Schema, fragt den Graphen nach Beziehungen und Nutzung, durchsucht die fachlichen Beschreibungen, wenn er keinen Namen kennt, und liest Quelltext zuletzt, nur dort, wo die genaue Logik entscheidet.
Was ein Agent damit gemacht hat
Beim Neubau einer 25 Jahre alten Dynpro-Anwendung hatte der Agent zwei Server: Sysparency MCP zum Verstehen, SAP ADT MCP 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.
Leitplanken
- Nur lesend. Alle sieben 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 HTTP. 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.