MCP Server SAP: LangGraph Multi-Tool-Agent für Manufacturing

Pexon Consulting | 13 Min. Lesezeit | 01.06.2026

TL;DR

Multi-Tool-Agents für Manufacturing scheitern selten am Modell, sondern an SAP. Wir haben 33 produktive KI-Agenten mit LangGraph als Orchestrator und MCP Server SAP-Adaptern gebaut. Dieser Artikel zeigt die Architektur, das Production-Order-Pattern und die Edge-Cases, die niemand auf Konferenzen erwähnt — von OData-Timeouts bis Berechtigungs-Hölle in S/4HANA.

Warum 33 Agenten kein Witz waren

Wir haben es vor ein paar Wochen auf LinkedIn gepostet: 33 produktive KI-Agenten in einem Manufacturing-Setup, alle gegen denselben MCP-Server-Layer für SAP. Das klingt nach Buzzword-Bingo, aber dahinter steckt ein sehr nüchterner Grund. Ein einziger „großer“ Agent, der alles kann, ist in einem Fertigungsbetrieb nicht steuerbar — weder regulatorisch noch organisatorisch. Der Produktionsplaner darf andere Daten sehen als der Einkäufer, der Qualitätsmanager braucht andere Tools als der Werker an der Maschine.

Statt einen Monolith-Agent zu bauen, haben wir 33 fokussierte Agents auf einer gemeinsamen Plattform aufgesetzt. Jeder Agent hat ein klares Aufgabengebiet (Fertigungsauftrag-Suche, Materialverfügbarkeit, Qualitätsmeldung, Wartungsplan, Lieferanten-Vergleich, etc.) und greift über genau dieselben MCP-Server auf SAP zu. Das spart Aufwand pro Agent dramatisch — der Wiederverwendungs-Effekt ab Agent Nummer fünf ist der eigentliche Hebel.

Was uns dabei überrascht hat: Die Suchanfragen sind da. Google Search Console zeigt uns 165 Impressions/Monat für „google drive mcp“ und steigend für „mcp server sap“ — ein Signal, dass IT-Leiter im Mittelstand das Thema aktiv recherchieren, aber kaum Production-Material finden. Genau die Lücke füllt dieser Artikel.

Die Architektur in drei Komponenten

+--------------+    +-------------------+    +----------------+
| User (Web /  |    | LangGraph         |    | MCP Server SAP |
| Teams / API) |--->| Orchestrator      |--->| (OData + RFC)  |
+--------------+    | - Tool-Routing    |    +----------------+
                    | - State / Memory  |             |
                    | - Token-Budget    |             v
                    +-------------------+    +----------------+
                              |              | SAP S/4HANA    |
                              v              +----------------+
                    +-------------------+
                    | weitere MCP Server|
                    | (Google Drive,    |
                    | SharePoint, MES)  |
                    +-------------------+

Drei Komponenten, klar getrennt:

1. LangGraph als Orchestrator – führt den Graph aus: Reihenfolge der Knoten, State, Token-Budget, Retry bei Fehlern. Welche SAP-Aufrufe in welcher Reihenfolge passieren, legt der Graph fest, nicht das Modell. Das ist seit der SAP API Policy 4.2026a der entscheidende Punkt, siehe Nachtrag oben.
2. MCP Server pro Datenquelle — ein dedizierter Server pro Backend-System (SAP, Google Drive, SharePoint, MES). Standardisiertes Protokoll, austauschbar.
3. Tool-Wrapper im Agent — der Agent kennt nur das MCP-Tool-Schema, nicht die SAP-Internals. Das ist der entscheidende Punkt für Wiederverwendung.

Der Vorteil dieser Trennung: Wenn morgen ein neuer Agent gebraucht wird, der Lieferanten-Daten kombiniert mit Fertigungsauftrags-Status, muss niemand mehr SAP-Code anfassen. Der MCP Server SAP existiert bereits, der Agent ruft ihn auf wie jede andere API. Das ist der Grund, warum Agent Nummer 33 nur 1,5 PT gekostet hat, während Agent Nummer 1 bei 25 PT lag.

MCP Server SAP — was wirklich nötig ist

Die kurze Antwort: Drei Tool-Familien. Read-Only-Queries (OData), strukturierte Schreiboperationen (BAPI / RFC), und Workflow-Trigger (Business Events). Alles andere ist Overengineering.

Unser MCP Server SAP exponiert pro produktivem Use Case maximal 8-12 Tools. Mehr braucht der Agent nicht — und mehr ist eine Falle, weil das LLM bei 30+ Tool-Definitionen anfängt, Tool-Argumente zu halluzinieren. Wir sehen das in jeder ersten PoC-Iteration: Teams exponieren 80 Tools, der Agent ruft das falsche, ein OData-Query läuft 4 Minuten und der User wartet im Frontend auf einen Timeout.

# vereinfachter MCP Server SAP via FastMCP
from fastmcp import FastMCP
from pyrfc import Connection

mcp = FastMCP("sap-production")

@mcp.tool()
async def find_production_order(
    material_number: str | None = None,
    order_status: str = "REL",
    plant: str = "1000",
    limit: int = 10,
) -> list[dict]:
    """Sucht Fertigungsauftraege in SAP. Default: nur freigegebene."""
    sap = Connection(**SAP_CONN)
    result = sap.call(
        "BAPI_PRODORD_GET_LIST",
        SELECTION={
            "MATERIAL": material_number,
            "ORDER_STATUS": order_status,
            "PLANT": plant,
        },
    )
    return result["PRODUCTION_ORDERS"][:limit]

Drei Patterns, die in jedem unserer SAP-MCP-Server vorkommen:

• Default-Werte für jeden Parameter — der Agent muss nicht jeden Parameter setzen können, sonst halluziniert er Werke und Sortimente
• Strikter limit-Cap — kein Tool darf mehr als 50 Datensätze zurückgeben, sonst sprengt der Output das Context-Window
• Strukturierte Beschreibung im Docstring — der Docstring wird vom LLM als Tool-Description gelesen, nicht von Menschen. Ein guter Docstring spart später drei Halluzinationen

Wer noch keinen MCP-Server für SAP hat: Das Model Context Protocol ist offen spezifiziert, FastMCP ist die schnellste Python-Implementierung. Setup für die ersten 5 Read-Only-Tools schaffen wir in 3-4 Tagen, inklusive lokalem Testing gegen SAP-Sandbox. Vor dem Bau gehört allerdings eine Entscheidung dazu: SAP stellt in der CAP-Dokumentation klar, dass ein selbst gebauter MCP-Adapter keine von SAP anerkannte Architektur im Sinne von Ziffer 2.2.2 der API Policy ist. Als gekapselte Integrationsschicht, deren Aufrufe der Graph in fester Reihenfolge anstoßt, bleibt er sinnvoll. Als freier Werkzeugkatalog für ein Modell führt der Weg über das MCP Gateway der SAP Integration Suite oder Joule Studio. Welche Variante für Sie gilt, gehört in die Architekturentscheidung und zu Ihrem SAP-Account-Team.

LangGraph als Orchestrator — der Multi-Tool-Pattern

LangGraph spielt seine Stärke nicht beim Single-Tool-Call aus, sondern beim Multi-Step-Workflow. Ein Beispiel: Der Werker fragt „Warum ist Auftrag 4711 noch nicht fertig?“ Der Agent muss in dieser Reihenfolge: (1) Auftrag finden, (2) Status-Historie laden, (3) Material-Verfügbarkeit checken, (4) Letzte Qualitätsmeldung lesen, (5) Antwort synthetisieren. Das ist ein klassischer Graph mit fünf Knoten und konditionalen Edges.

from langgraph.graph import StateGraph, END
from langgraph.prebuilt import create_react_agent

workflow = StateGraph(AgentState)

# Knoten = einzelne Tool-Aufrufe oder LLM-Entscheidungen
workflow.add_node("agent", llm_with_tools)
workflow.add_node("tools", tool_executor)
workflow.add_node("summarize", final_summarizer)

# Edges = Routing-Logik
workflow.set_entry_point("agent")
workflow.add_conditional_edges(
    "agent",
    should_continue,
    {"continue": "tools", "summarize": "summarize", "end": END},
)
workflow.add_edge("tools", "agent")
workflow.add_edge("summarize", END)

graph = workflow.compile(checkpointer=postgres_saver)

Drei Pattern-Entscheidungen, die wir bei jedem Manufacturing-Agent treffen:

• max_iterations = 8 als Hard-Cap. Kein produktiver Use Case in der Fertigung braucht mehr als 8 Tool-Calls. Wenn der Agent nach 8 Calls noch keine Antwort hat, ist die Frage zu komplex und der Loop wird sauber abgebrochen — der User sieht eine Eskalation an einen Menschen statt einer halluzinierten Antwort.
• Tool-Routing per tool_choice="auto" innerhalb eines Knotens, dessen zulässige Werkzeuge der Graph vorgibt, mit System-Prompt-Hint, welcher Tool-Cluster zuerst zu prüfen ist. Das spart pro Conversation ca. 1.500 Tokens (kein Tool-Description-Re-Reading bei jedem Step). Bei SAP-Werkzeugen ist genau diese Auswahl der Punkt, den Ziffer 2.2.2 der SAP API Policy adressiert; dort legt der Graph die Aufruffolge fest, statt sie dem Modell zu überlassen.
• Separater summarize-Knoten statt finaler LLM-Call im Agent-Loop. Das reduziert die Output-Token-Last und macht die finale Antwort konsistenter, weil der Summarizer mit einem reduzierten Prompt arbeitet.

In unserem 33-Agenten-Setup ist der LangGraph-Code pro Agent gerade noch 80-150 Zeilen. Den Rest erledigen geteilte Komponenten — MCP-Server, Checkpointer, Auth-Middleware, Observability.

Production-Order-Pattern — ein konkretes Beispiel

Konkret wird es am Production-Order-Pattern, dem häufigsten Use Case in unseren Manufacturing-Projekten. Der Werker oder Produktionsplaner stellt eine natürlichsprachige Frage zu einem Fertigungsauftrag, der Agent löst sie über mehrere SAP-Tabellen auf.

Frage: „Hat Auftrag 4711 alle Komponenten und wann wird er voraussichtlich fertig?“

Der Agent führt im Hintergrund diese Steps aus:

Der Agent generiert dann eine natürlichsprachige Antwort wie: „Auftrag 4711 hat 5 von 7 Komponenten verfügbar. M-003 wird laut MD04 am 04.06. erwartet, M-007 ist überfällig (Lieferant: ACME GmbH, Bestellnummer 4500001234). Mit aktueller Kapazitätslast an ASSY-1 ist der Auftrag voraussichtlich am 06.06. fertig — nur wenn M-007 bis spätestens 05.06. eintrifft.“

Diese Antwort hat im Schnitt 7.000 Tokens Output (Tool-Calls plus Synthesis), kostet bei Claude Sonnet 4 etwa 0,12 EUR und kommt in 18-22 Sekunden. Vergleichen Sie das mit der Alternative: Ein Produktionsplaner, der dieselbe Information manuell aus vier SAP-Transaktionen zusammensucht, braucht im Schnitt 8-12 Minuten. Bei 80-100 solcher Abfragen pro Tag in einer mittelständischen Fertigung sind das 13-20 freigespielte Personenstunden pro Tag — das ist der eigentliche Business Case.

Berechtigungs-Hölle: Wie SAP-Auth in MCP-Servern wirklich aussieht

Jetzt zum Teil, den die meisten Blog-Posts überspringen: Auth. Ein MCP Server SAP kann nicht einfach mit einem Service-User auf alles zugreifen. SAP-Berechtigungen sind objektbasiert (S_TCODE, S_TABU_DIS, S_DEVELOP, etc.) und unterscheiden je Buchungskreis, Werk und Sparte. Der Agent muss im Namen des aufrufenden Users handeln, nicht im Namen eines technischen Sammel-Accounts.

Wir lösen das mit einem dreistufigen Modell:

1. User-Auth via Entra ID — der User loggt sich am Web-Frontend mit seinem Microsoft-Account ein. Standard OAuth-Flow, nichts SAP-spezifisches.
2. Token-Exchange zu SAP — das Backend tauscht den Entra-Token gegen ein SAP-Logon-Ticket via SAP-Cloud-Connector + Principal Propagation. Damit hat der MCP-Server-Call exakt die Rechte des Users, nicht mehr.
3. Audit-Trail in der MCP-Server-Middleware — jeder Tool-Call wird mit User-ID, Zeitstempel, Tool-Name, Input und Output in einer Audit-Tabelle persistiert. Das ist DSGVO-Pflicht und in regulierten Branchen wie Pharma- oder Lebensmittel-Fertigung auch revisionsrelevant.

@mcp.tool()
async def find_production_order(
    material_number: str | None = None,
    plant: str = "1000",
    ctx: ToolContext = None,  # FastMCP injiziert User-Context
) -> list[dict]:
    user = ctx.user_id
    if not user_has_plant_access(user, plant):
        raise PermissionError(f"User {user} hat keinen Zugriff auf Werk {plant}")
    log_audit(user, "find_production_order", {"plant": plant})
    return sap_call_with_user_context(user, "BAPI_PRODORD_GET_LIST", ...)

Das ist der Punkt, an dem die meisten PoCs sterben. Ein lokaler Prototyp mit Service-User funktioniert in 2 Wochen, ein produktiver Agent mit echter User-Auth braucht zusätzlich 2-3 Wochen für SAP-Cloud-Connector-Setup, Entra-Mapping und Berechtigungsprüfung pro Tool.

Wir raten aktuell davon ab, einen Manufacturing-Agent ohne Principal Propagation auszurollen. Das einzige Mal, dass wir das anders gemacht haben, war ein streng read-only Reporting-Agent mit Service-User und vorgelagerter Berechtigungsprüfung im Web-Frontend — der war nach 4 Monaten Audit-Findings zur Komplett-Überarbeitung gezwungen.

Die Edge-Cases, die niemand auf der Konferenz erwähnt

Aus unseren 33 Agenten gibt es eine Liste von Edge-Cases, die in jedem Manufacturing-Projekt wiederkommen — und in keinem Vendor-Whitepaper auftauchen:

OData-Timeout-Kaskade. SAP-OData-Endpoints haben einen Default-Timeout von 30 Sekunden, manche Queries auf MD04 brauchen aber 45-60 Sekunden bei großen Werken. Der MCP-Server muss explizit längere Timeouts setzen UND ein asynchrones Polling-Pattern für richtig große Reports anbieten (z.B. BAPI_PRODORD_GET_LIST mit BACKGROUND_PROCESSING = 'X').

Datums-Hölle. SAP gibt Datumsfelder mal als YYYYMMDD-String zurück, mal als ISO, mal als JavaScript-Timestamp. Der LLM versteht das mal richtig, mal nicht. Wir normalisieren alle Datumsfelder im MCP-Server zu ISO-8601, nie im Agent. Spart einen Halluzinations-Vektor.

Mandantenfähigkeit bei Holding-Strukturen. Wenn der Kunde mehrere SAP-Mandanten betreibt (typisch bei Holdings mit eigenständigen Töchtern), muss der Mandant Teil des Auth-Tokens sein, nicht hardgecodet im MCP-Server. Wir lösen das über einen Pre-Auth-Step, der den Mandanten aus dem User-Profil zieht.

Sprachverwirrung bei Materialtexten. SAP-Materialtexte sind oft mehrsprachig (DE, EN, FR). Der Agent muss wissen, welche Sprache der User braucht. Wir injizieren die User-Sprache via System-Prompt — der LLM filtert dann beim Material-Lookup richtig.

Race Conditions bei parallelen Tool-Calls. LangGraph kann mehrere Tool-Calls in einem Step parallel ausführen. Bei SAP-BAPIs mit COMMIT_WORK führt das zu Sperr-Konflikten. Lösung: Schreibende Tools immer sequentiell ausführen, nur Read-Tools parallel.

Konfidenz: hoch bei OData/Datums-Themen, mittel bei Holding-Mandanten (kommt nicht in jedem Projekt vor). Unsere Empfehlung: Diese 5 Punkte in den Sprint-1-Backlog jedes Manufacturing-Agent-Projekts aufnehmen — nicht später, wenn der Code schon steht.

Kosten und Zeitrahmen

Transparent, ohne Marketing-Glättung. Ein produktiver Multi-Tool-Agent mit MCP Server SAP kostet uns:

Ab Agent Nummer zwei sinkt der Aufwand auf 4-8 PT pro Agent (5.000 – 10.000 EUR), weil MCP-Server, Auth-Layer und Observability einmal stehen. Bei 10 Agenten landen Sie typischerweise bei 110.000-150.000 EUR Gesamt-Investment, was sich bei 80-100 Anfragen/Tag pro Agent meist innerhalb von 8-14 Monaten amortisiert.

Laufende Kosten: LLM-Tokens (~600-1.200 EUR/Monat bei moderater Nutzung), Hosting auf AKS (~400-800 EUR/Monat), MCP-Server-Wartung (~2 PT/Monat).

Was wir aus 33 Agenten gelernt haben

Drei Erkenntnisse, die jeder bei Agent Nummer drei machen wird — wir geben sie hier vor:

1. Ein MCP-Server pro Backend, nicht pro Agent. Wer für jeden Agent einen eigenen SAP-Wrapper baut, hat nach Agent fünf einen unwartbaren Wildwuchs. Die Investment-Logik dreht sich erst ab MCP-Server-Wiederverwendung.
2. Observability ist nicht optional. Ohne langsmith oder Phoenix ist jeder Bug ein Blindflug. Token-Verbrauch, Tool-Call-Erfolgsraten und Latenz pro Tool müssen vom Tag-1 sichtbar sein.
3. Den User vor zu vielen Tool-Calls schützen. Wenn ein Agent sieben Sekunden auf eine SAP-Query wartet, muss das im Frontend sichtbar sein („prüft Materialverfügbarkeit…“). Sonst hält der User das System für tot und reloaded.

Unsere klare Empfehlung für jeden, der über Multi-Tool-Agents in Fertigung nachdenkt: Fangen Sie mit dem MCP-Server an, nicht mit dem Agent. Das ist die teurere und langlebigere Investition. Der Agent ist relativ austauschbar — ob LangGraph, Semantic Kernel oder in zwei Jahren etwas Neues, die Schnittstelle zu SAP über MCP bleibt.

Häufig gestellte Fragen

Was ist ein MCP Server SAP konkret?

Ein MCP Server SAP ist eine eigenständige Anwendung, die nach dem Model-Context-Protocol-Standard Tools für SAP-Datenzugriff bereitstellt. Statt dass jeder Agent direkt mit SAP-OData oder RFC kommuniziert, ruft er den MCP-Server auf, der die SAP-Internals kapselt. Das macht Agents austauschbar und SAP-Anbindung wiederverwendbar.

Funktioniert das mit SAP S/4HANA und SAP ECC?

Ja, beide. S/4HANA ist über OData-V4-Services in der Regel sauberer anzubinden, ECC braucht teilweise klassische RFC-Bausteine via pyrfc oder den Java-Connector. Die MCP-Tool-Schnittstelle zum Agent ist in beiden Fällen identisch — der Unterschied liegt komplett im MCP-Server-Backend.

Brauche ich eine eigene KI-Infrastruktur oder reicht Azure OpenAI?

Für die meisten Mittelstands-Fertigungen reicht Azure OpenAI mit Private-Networking-Setup. Wer regulatorisch (Rüstung, Pharma, Public) keine Cloud-LLMs darf, dem empfehlen wir Private KI-Infrastruktur mit Llama 3.3 oder Qwen 2.5 auf eigenen GPUs. LangGraph und MCP sind in beiden Fällen identisch.

Wie wird verhindert, dass der Agent falsche oder gefährliche SAP-Operationen ausführt?

Vier Schichten: (1) Read-Only-Tools sind Default, Write-Tools nur in expliziten Use Cases. (2) Schreibende BAPIs werden vor Ausführung dem User zur Bestätigung vorgelegt („Möchten Sie Auftrag 4711 freigeben?“). (3) Berechtigungen werden auf SAP-Seite durch Principal Propagation enforced — der Agent kann nichts tun, was der User nicht selbst dürfte. (4) Vollständiger Audit-Trail jeder Aktion. Diese vier Schichten senken das Betriebsrisiko. Die Frage aus Ziffer 2.2.2 der SAP API Policy 4.2026a beantworten sie nicht, denn dort geht es darum, wer die Abfolge der API-Aufrufe auswählt. Deshalb legen wir sie im Graph fest und klären mit Ihrem SAP-Account-Team, ob stattdessen ein von SAP vorgesehener Weg der richtige ist.

Wie lange dauert ein erster produktiver Agent realistisch?

10 Wochen bei einem fokussierten Team aus 2 Engineers plus SAP-Berater. Das schließt MCP-Server-Setup, Auth, Audit und ein einziges Use Case ein. Wer schon einen MCP-Server hat (z.B. aus einem Vorprojekt), ist bei 4-5 Wochen pro weiterem Agent. Schnellere Versprechungen sind in unserer Erfahrung nur PoCs ohne Production-Auth oder ohne Observability.

Ist ein selbst gebauter MCP-Server für SAP nach der SAP API Policy zulässig?

Das hängt daran, wer die Aufruffolge bestimmt. Ziffer 2.2.2 der SAP API Policy 4.2026a untersagt die Anbindung generativer oder (teil-)autonomer KI-Systeme, die Abfolgen von API-Aufrufen planen, auswählen oder ausführen, außer über von SAP vorgesehene Wege. SAP schreibt in der CAP-Dokumentation ausdrücklich, dass ein selbst gebauter MCP-Adapter keine anerkannte Architektur im Sinne dieser Ziffer ist. Praktisch heißt das: Ein eigener MCP-Server als gekapselte Integrationsschicht, deren Aufrufe der Graph in fester Reihenfolge anstoßt, ist etwas anderes als ein Werkzeugkatalog, aus dem sich das Modell frei bedient. Die Bedingungen für Drittanbieter-MCP-Server nennt SAP in der Referenzarchitektur Third-Party MCP Access to SAP Solutions, die Betriebsverantwortung liegt dann beim Kunden. Soll das Modell wirklich selbst entscheiden, welchen SAP-Dienst es als Nächstes aufruft, führt der Weg über das MCP Gateway der SAP Integration Suite, SAP-eigene MCP-Server über Joule Studio oder A2A. Verbindlich ist für Ihre Landschaft nur Ihr SAP-Vertrag oder Ihr SAP-Account-Team; das ist kein Rechtsrat, sondern der Stand der öffentlichen SAP-Dokumentation zum 18.09.2026.

Nächster Schritt

Wenn Sie in Ihrer Fertigung über Multi-Tool-Agents nachdenken oder bereits einen Prototypen haben, der den Sprung in Produktion nicht schafft: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — mit Ihrem SAP-Mandanten, einem ersten produktiven Use Case und einer ehrlichen Roadmap zu Agent Nummer fünf, zehn und dreißig.

Verwandte Themen