bw-modeling-mcp

A Model Context Protocol (MCP) server that enables AI assistants like Claude to work directly inside SAP BW/4HANA or SAP BW 7.5 on HANA systems — reading, creating and modifying BW modeling objects via the same internal SAP APIs that Eclipse BWMT and the BW/4HANA Cockpit use: the BW Modeling REST API (/sap/bw/modeling/) for objects, queries and live data, the ADT API (/sap/bc/adt/) for the ABAP and AMDP routines BW generates, the BW/4HANA manage API for the request monitor and runtime, and the Push API (/sap/bw4/) for data loads.

This is not a simulation. Every tool call connects to a live BW system — write operations produce real changes.

---

☁️ Running on SAP BTP Cloud Foundry

Besides stdio, the server can run as an HTTP service on SAP BTP Cloud Foundry with XSUAA OAuth in front and a BTP destination behind — either a shared technical user (BasicAuthentication) or principal propagation, where each caller reaches BW as themselves and BW applies their own authorizations.

Three role collections decide what a user is offered: BW MCP Reader (everything that only reads), BW MCP Analyst (a small reporting client — run queries and understand what they return) and BW MCP Developer (everything, including changes). stdio is unchanged — npm start behaves exactly as before. Setup: docs/CENTRAL-HOSTING-SETUP.md (step-by-step) and docs/CLOUD-FOUNDRY.md (reference).

What central hosting changes

Scenario	stdio only	Hosted on BTP
One analyst, one BW system	runs on the analyst's machine	server-side, the analyst logs in with their own identity
Several analysts, one server	not possible, no central auth	all log in via BTP, each caller's identity reaches BW
Tool permissions	none — whoever runs it can call every tool	granted per role, independent of BW authorizations: a BW developer can be read-only in the MCP, or the querying tools can be withheld from someone who may otherwise view data
BW authorizations	enforced through the user's own credentials	unchanged, still fully enforced — with principal propagation each caller acts as themselves, never as a shared identity
Audit trail	limited	XSUAA logs every login; with principal propagation the BW session log shows the real user

A new tool stays unavailable to read-only callers until it is explicitly classified as a read, so the surface never widens by accident; write implies read, never the reverse. The three role collections are a starting point and can be split further in xs-security.json. Principal propagation additionally needs a certificate rule and ICM trust on the BW side.

---

System Compatibility