S/4HANA MCP Server

Ein MCP-Server, der 38 Tools für SAP S/4HANA (Cloud Public Edition und On-Premise Private Edition) über OData V2, OData V4 und SOAP bereitstellt: Geschäftspartner, Produkte, Verkaufspreise, Lager, Bestellungen, Einkaufsinfosätze, Lieferantenrechnungen (einschließlich Buchen und Stornieren), Leistungserfassungsblätter, Buchhaltungsbelege, Kostenstellen und Finanz-Organisationsstruktur.

Schreib-Tools (create_*, cancel_supplier_invoice, check_invoice_posting_readiness) und get_finance_structure geben ihr Ergebnis direkt als JSON zurück. Jedes andere (Lese-)Tool schreibt sein Ergebnis – CSV für Sammlungen, Markdown für einzelne Datensätze – in eine E2B-Sandbox und gibt die Dateipfade zurück, anstatt potenziell große SAP-Ergebnismengen (Hunderte von Geschäftspartnern, vollständige Buchhaltungsbeleg-Positionsdetails usw.) direkt in den Kontext des aufrufenden Agents einzubetten. Dieser Server verbindet sich nur mit einer E2B-Sandbox, die Ihr MCP-Client bereits besitzt – er erstellt niemals eine. Ihr Client benötigt eine eigene E2B-Integration (das E2B SDK oder eine Claude-Umgebung mit passendem Code-Ausführungszugriff), um die Dateien zurückzulesen; siehe E2B-Sandbox-Einrichtung.

Schnellstart

git clone https://github.com/ilia-inovaflow/s4hana-mcp-server.git
cd s4hana-mcp-server
npm install
npm run build
cp .env.example .env   # fill in your E2B sandbox + SAP connection details
npm start               # stdio transport (Claude Desktop, MCP Inspector, etc.)

Für die lokale Entwicklung ohne vorheriges Builden: npm run dev.

Related MCP server: SAP OData MCP Server

E2B-Sandbox-Einrichtung

Registrieren Sie sich für einen kostenlosen API-Schlüssel unter e2b.dev, starten Sie dann eine Sandbox (oder verwenden Sie eine vorhandene), aus der Ihr MCP-Client Dateien lesen kann, und setzen Sie:

E2B_API_KEY=<your E2B API key>
SANDBOX_ID=<an already-running sandbox ID>   # stdio only — HTTP takes this per-session

Über den HTTP-Transport wird SANDBOX_ID stattdessen pro Sitzung über den sandbox-id-Request-Header bereitgestellt – nützlich, wenn eine laufende Serverinstanz mehrere Aufrufer mit jeweils eigener Sandbox bedient.

Dies hat nichts mit dem eigenen sandbox.api.sap.com-Testhost von SAP weiter unten zu tun – „Sandbox“ bedeutet in dieser README zwei verschiedene Dinge.

Testen ohne eigenen SAP-Mandanten

SAP veröffentlicht eine kostenlose, öffentliche, schreibgeschützte API-Sandbox unter sandbox.api.sap.com, mit der dieser Server sofort kommuniziert. Registrieren Sie sich für einen kostenlosen API-Schlüssel unter api.sap.com und setzen Sie dann:

SAP_HOST=https://sandbox.api.sap.com
SAP_CLIENT_ID=<your sandbox API key>

Kein Benutzername, Passwort oder OAuth-Setup erforderlich – die Sandbox authentifiziert sich mit einem einzigen APIKey-Header. Geschäftspartner-, Produkt- und Preistools funktionieren sofort mit den Sandbox-Demodaten (Sie benötigen weiterhin die obige E2B-Sandbox, um Lese-Tool-Ergebnisse zu empfangen).

Verbinden mit einem echten SAP-Mandanten

Setzen Sie SAP_HOST auf Ihre Mandanten-URL und wählen Sie einen von drei Authentifizierungsmodi über SAP_AUTH_MODE:

SAP_CLIENT (die SAP-Client-/Mandantennummer, z. B. 100) standardmäßig auf 100, falls nicht gesetzt.

Zwei API-Familien benötigen laut SAP-Design Basic- oder X.509-Authentifizierung und lehnen OAuth ab: Buchhaltungsbeleg-Buchung (create_journal_entry, SOAP SAP_COM_0002) und die Detailansichten des Buchhaltungsbelegs (get_journal_entry, search_journal_entries mit document_level=true). Alles andere funktioniert unter allen drei Modi.

Siehe .env.example für die vollständige Variablenliste, einschließlich des optionalen SAP_JE_SOAP_PATH-Overrides, das einige On-Premise-SOAMANAGER-Konfigurationen benötigen.

Transporte

stdio (Standard, npm start / npm run dev) – eine SAP-Verbindung und eine E2B-Sandbox pro Prozess, vollständig über .env konfiguriert. Das ist, was Claude Desktop und die meisten lokalen MCP-Clients erwarten:

{
  "mcpServers": {
    "s4hana": {
      "command": "node",
      "args": ["/absolute/path/to/s4hana-mcp-server/dist/index.js"],
      "env": {
        "E2B_API_KEY": "...", "SANDBOX_ID": "...",
        "SAP_HOST": "...", "SAP_AUTH_MODE": "basic", "SAP_USERNAME": "...", "SAP_PASSWORD": "..."
      }
    }
  }
}

Streamable HTTP (npm run start:http / npm run dev:http) – für Remote- oder Multi-Tenant-Bereitstellung. Die SAP-Verbindung jeder Sitzung wird entweder über .env-Standardwerte oder über Pro-Request-Header konfiguriert (sap-host, sap-auth-mode, sap-username, sap-password, sap-token-url, sap-client-id, sap-client-secret, sap-client, sap-je-soap-path), und ihre E2B-Sandbox über den sandbox-id-Header (oder SANDBOX_ID-Env als Fallback) – so kann ein laufender Server Anfragen gegen verschiedene Mandanten und Sandboxes bearbeiten. E2B_API_KEY wird immer aus der eigenen Umgebung des Servers gelesen. PORT (Standard 3000) und HOST (Standard localhost) konfigurieren den Listener; der MCP-Endpunkt ist POST /mcp, mit GET /health für Liveness-Checks.

Wenn Sie den HTTP-Transport irgendwo bereitstellen, das über das Netzwerk erreichbar ist, platzieren Sie ihn hinter Ihrer eigenen Authentifizierungs-/Netzwerkgrenze – dieser Server selbst schützt den Zugriff auf den /mcp-Endpunkt nicht, nur die nachgelagerte SAP-Verbindung.

Tools

• search_business_partners – Kunden, Lieferanten, Personen, Organisationen suchen

• get_business_partner – vollständige Details für einen Geschäftspartner

• query_business_partner_odata – generische Abfrage gegen beliebige API_BUSINESS_PARTNER-Entitätsmengen

• search_products – Materialien, Fertigprodukte, Dienstleistungen, Rohstoffe suchen

• get_product – vollständige Details für ein Produkt

• query_product_odata – generische Abfrage gegen beliebige API_PRODUCT_SRV-Entitätsmengen

• get_product_pricing – kombinierte Preissuche für ein Material (hier beginnen für „Was kostet X“)

• search_pricing_conditions – Konditionssätze nach Typ/Rate durchsuchen

• get_pricing_condition – vollständige Details für einen Konditionssatz

• query_pricing_odata – generische Abfrage gegen beliebige Preis-Entitätsmengen

• list_warehouses

• get_warehouse

• search_purchase_orders

• get_purchase_order

• query_purchase_order_odata – generische Abfrage, einschließlich Position/Planlieferungsebene

• get_purchase_order_confirmations – Lieferantenbestell-/Versand-/Wareneingangsbestätigungen, Massenabfrage

• search_purchasing_info_records

• get_purchasing_info_record

• query_purchasing_info_record_odata

• search_supplier_invoices

• get_supplier_invoice

• query_supplier_invoice_odata

• create_supplier_invoice_po ⚠️ Schreiben – Rechnung mit Bestellbezug (3-Wege-Abgleich)

• create_supplier_invoice_gl ⚠️ Schreiben – Nicht-Bestellungs-Ausgabenrechnung, direkte Sachkontenpositionen

• create_supplier_credit_memo ⚠️ Schreiben – Gutschrift mit Bestellbezug

• cancel_supplier_invoice ⚠️ Schreiben – storniert eine gebuchte Rechnung oder Gutschrift

• check_invoice_posting_readiness – schreibgeschützter Pre-Flight-Guard-Check

• search_service_entry_sheets

• get_service_entry_sheet

• query_service_entry_sheet_odata

• create_journal_entry ⚠️ Schreiben – bucht ein Sachkontenbeleg (SOAP, nur Basic/X.509-Authentifizierung)

• search_journal_entries – analytische (aggregierte) oder Buchhaltungsbeleg- (Positionsebene) Ansicht

• get_journal_entry – ein Buchhaltungsbeleg nach Nummer

• search_gl_accounts

• search_open_po_items – die noch fakturierbaren Bestellpositionen eines Lieferanten in einem Aufruf

• search_cost_centers

• get_cost_center_hierarchy – der Standard-Kostenstellenhierarchiebaum

• get_finance_structure – Buchungskreise, Ledger, Kontenpläne, Segmente, Geschäftsbereiche

Jedes Schreib-Tool führt serverseitige Guard-Checks (Existenz, Sperrflags, Duplikaterkennung, Saldenvalidierung) vor dem Buchen durch und meldet eine strukturierte Begründungsliste – ohne etwas an SAP zu senden –, wenn ein Guard fehlschlägt. Deterministische SAP-Ablehnungen (geschlossene Buchungsperioden, fehlende Steuerzuständigkeit usw.) werden in umsetzbare Meldungen übersetzt, anstatt rohe Fehlercodes zu liefern.

Architektur

src/
├── server.ts       # McpServer factory — tool registration, schemas, annotations
├── client.ts        # SapClient — OData V2/V4 requests, CSRF-protected writes, SOAP posts
├── auth.ts           # Auth strategies: Basic, OAuth Client Credentials, OAuth Authorization Code
├── config.ts          # Connection config + SAP public sandbox detection
├── index.ts             # stdio entry point
├── http.ts               # Streamable HTTP entry point (Express, per-session auth)
└── tools/
    ├── shared.ts          # OData/CSV/error-parsing + E2B sandbox file I/O, shared by every tool
    └── *.ts                # one file per tool (schema + handler)

Schreibvorgänge auf OData-V2-Endpunkte folgen dem CSRF-Token-Protokoll von SAP: Token per GET mit X-CSRF-Token: Fetch abrufen, mit dem Session-Cookie beim POST erneut senden, bei einem 403 einmal wiederholen. Die Buchung von Buchhaltungsbelegen erstellt und sendet stattdessen einen rohen SOAP-Envelope, da diese API kein OData-Äquivalent hat.

Entwicklung

npm run dev        # stdio, hot reload via tsx
npm run dev:http    # HTTP, hot reload via tsx
npm run typecheck    # tsc --noEmit
npm run build          # compile to dist/

Lizenz

MIT