Agentic AI for SAP BW

Through the BICS interface, the agent also works directly with the data itself. It executes queries or queries an InfoProvider using variables, filters, and navigation through hierarchies - even if no query exists for that purpose yet. You can ask questions such as

“Show me the five top-selling products for each month”

the agent finds the appropriate provider, understands the data model, aggregates the data, and returns the result directly in the chat. For business users, there is a dedicated role for this in the central operations environment with a deliberately limited set of tools that includes only querying and understanding the data, leaving modeling out of the picture.

Technically, the server translates the agent's calls into requests to four SAP interfaces: the BW Modeling REST API for objects, queries and live data; the ADT API for the ABAP and AMDP routines generated by BW itself; the Manage API for the Request Monitor and runtime; and the Push API for data loads. This ensures that the agent follows exactly the paths into the system that SAP has designated for modeling. What a developer does in Eclipse, click by click, the agent formulates as a prompt. There is no second, custom-built access path into the system.

When writing, it follows the BW locking protocol. It locks the object, reads its current XML, applies the change, writes everything back in full, activates it, and unlocks it again - exactly the same mechanism that Eclipse uses. The same syntax and activation checks as in the standard system are applied, ensuring that the result is a properly activated and consistent object. Every change is added to a transport request and travels through the system landscape via the usual transport path all the way to Q and P.

The server is open source under the MIT license, written in TypeScript, and can be installed via npm. Development takes place openly on GitHub, so every line of code is visible and you can track what’s happening in your own system at any time.

There are two ways to run the server, and both are considered equally valid.

Locally, the agent-based environment - such as Claude Code - starts the server as a Node.js process on the developer’s computer; the access credentials are stored in a local configuration file. This is the fastest way for a single person to get started. Despite its name, the server in this case is not a continuously running service, but rather a program that is active only during the work session. It only becomes a true service when run centrally.

Centrally, the same server runs as an HTTP service on SAP BTP Cloud Foundry. Login is handled by XSUAA, the BTP authentication service that a company is already using, and behind the scenes, a BTP destination routes traffic to BW via the Cloud Connector. The client only needs the URL; the browser handles the rest of the login process. This allows multiple people to work with a shared service without anyone having to install anything locally.

In centralized operation, the server comes with three default roles. The BW MCP Analyst receives only what is necessary for querying and understanding the data; the BW MCP Reader receives all read-only tools; and the BW MCP Developer receives the full toolkit. A Reader is not merely denied write tools - they do not even appear in their tool list, so the AI cannot even suggest an unauthorized call. Below that level, BW itself still takes over. Through principal propagation, everyone works on behalf of their actual user with that user’s own authorizations - not via a shared technical collective user - and XSUAA logs every login. The MCP role is the first gate, and the BW authorization is the second.
This was made possible by the groundwork laid by Marian Zeis. He had already extracted the XSUAA mechanism for his own ABAP MCP server, ARC-1, as a standalone package and the BW Modeling MCP Server relies precisely on this.

The server really shines when used in conjunction with an ABAP MCP server such as ARC-1. For logic in ABAP and SQLScript, the two work hand in hand - exactly the division of labor familiar from Eclipse between the BW Modeling Tools and the ABAP Development Tools. A real-world example illustrates just how beneficial this is.

An energy provider is phasing out its SAP IS-U environment - which has grown over the years - and migrating billing to S/4HANA for Utilities. The underlying BW/4HANA remains in place, while the source system beneath it is completely replaced. This eliminates all the data enrichment that used to be handled via customer exits in the source system - and that’s exactly what’s missing from the reports later on.

This is where the two servers really shine. First, the agent uses the BW MCP Server to connect the DataSources from the new system to the existing providers and maps the standard fields. Next comes the gap analysis. For each missing field, it queries the legacy system directly via the ABAP MCP Server to determine which table it originated from and what ABAP logic was used to derive it. To recreate the system, it connects a CDS-based DataSource to each lookup table, sets up the staging environment and ported the old logic into an AMDP routine on the new foundation. For commissioning, it extends the load steps and process chains, starts the test load, and verifies the results directly in the system.