Introduction

MCP Servers can now be built and deployed on SAP Integration Suite, turning existing OData services and other SAP APIs into tools that MCP-capable clients can discover and invoke. For guidance on what to expose as MCP tools and how to think about the design, see my earlier post: Building MCP Servers with SAP Integration Suite — what to design, not just how.

Once your MCP Server is running, the next question is inevitable: how does the identity of the calling user reach the backend? For on-premise (or private cloud) SAP systems reachable via SAP Cloud Connector, the answer is Principal Propagation — the same mechanism used by every other BTP-to-on-premise integration scenario.

This post covers the end-to-end setup for the generic case: any MCP client (MCP Inspector, Joule Work Desktop, etc.) authenticating against SAP Default or IAS IdP, calling an MCP Server artifact on SAP Integration Suite, which then reaches S/4HANA on-premise through Cloud Connector as the real calling user.

Note: A parallel guide already exists for the Copilot Studio and Microsoft Entra ID — see SAP × Microsoft Copilot Studio — MCP Gateway guides series, Guide 04 for that variant, which also contains a thorough ABAP-side walkthrough.

The working example used throughout this post is API_BUSINESS_PARTNER on S/4HANA on-premise; the same setup applies identically to S/4HANA private cloud.

Scope: This post covers on-premise and private cloud ABAP systems reachable via Cloud Connector. For S/4HANA Public Cloud, the mechanism is different — the destination uses OAuth2SAMLBearerAssertion instead of PrincipalPropagation, and no Cloud Connector is involved. That scenario is covered in detail by blogpost: MCP Server with Integration Suite, expose S/4HANA Public Cloud API via OAuth2SAMLBearer.

Architecture

At the highest level, four hops carry user identity from an MCP client all the way to a real SAP user in S/4HANA — JWT on the BTP side, X.509 on the Cloud Connector side:

Prerequisites

BTP Subaccount

• A business-user OIDC IdP is active: either SAP Default (sap.default, present out of the box) or a customer IAS tenant configured as a business-user OIDC IdP under Security → Trust Configuration.
• The calling user has the API.invoke role assigned — either directly via a role collection, or as part of a custom one. This is the built-in Integration Suite role that gates all API and MCP Server calls from IdP users. See Creating a Custom Role Collection for Fine-Grained Access Control for how to set this up.

Cloud Connector

For the complete certificate generation walkthrough — System Certificate, CA Certificate, and User/Sample Certificate — follow Navin Krishnan's blog, which covers each step in detail.

Validate that:

• System Certificate — used for the CC-to-S/4 mTLS handshake; downloaded and imported later into S/4's STRUST.
• CA Certificate — the CA that signs every short-lived user certificate CPI mints per request.
• User (Sample) Certificate — generated with a Subject Pattern such as ${mail} or ${user_uuid}; used to define the mapping rule in CERTRULE on the backend.
• System mapping for the S/4 backend, with Principal Type = X.509 Certificate (General Usage).
• Principal Propagation is synced from the subaccount: Cloud to On-Premises → Principal Propagation → Synchronize. The Trust Configuration table must show at least two IDP entries — if it shows (0), PP will silently fail inside CPI before any request reaches the tunnel.

S/4HANA (on-premise / private cloud)

Validate that:

• STRUST: the CC System Certificate is imported into the SSL Server Standard PSE.
• CERTRULE: the sample user certificate is imported and a rule mapping the certificate attribute (e.g. E-Mail) to SU01 users is defined.
• RZ10:
  • icm/trusted_reverse_proxy_0 = SUBJECT=”CN=<system-cert-CN>”, ISSUER=”CN=<CA-CN>”
  • login/certificate_mapping_rulebased = 1
• SMICM: hard-restart ICM only if you changed the RZ10 profile parameters above.

SAP Integration Suite — Destination

Create a destination on the subaccount with:

Property Value

The virtual host and port must match the CC system mapping exactly. Reference this destination from the HTTP receiver in your MCP Server artifact.

Building and Registering the MCP Server

Deploy the MCP Server

SAP Integration Suite lets you create an MCP Server directly from an OpenAPI specification. The steps below use API_BUSINESS_PARTNER API as the example.

1. Download the OpenAPI specification

Download the OpenAPI specification file for your target API from the SAP Business Accelerator Hub:

• Business Partner

2. Create and configure the MCP Server artifact

In Integration Suite, go to Design → Integrations and APIs and create a new artifact. Choose MCP Server as the artifact type, then set the source type to HTTP Endpoint with OpenAPI Specification and fill in the following:

Property Value

3. Select tools to expose

From the parsed spec, select the operations you want to expose as MCP tools. A maximum of 30 tools can be included per MCP Server artifact.

4. Configure Authentication

Leave the Authentication policy settings as-is — the default configuration handles the inbound JWT validation automatically.

5. Configure Authorization

Under Authorization, keep the default API.invoke role. Ensure this role is assigned to the calling user via a role collection (see Prerequisites).

6. Deploy

Before deploying, you can optionally add Security or Traffic Management policies to the MCP Server artifact — for example, rate limiting or IP allowlisting. These are applied in the Policies tab if required.

Once you ready, deploy the MCP Server. Note the MCP URL of the deployed artifact.

Publish as an API Product in Developer Hub

Once deployed, the MCP Server needs to be published as a product in Developer Hub so clients can discover it and obtain OAuth credentials.

1. Open Developer Hub → Admin Center → Content.

2. Select your Business System → Integration Suite.

   

3. Select the MCP Server artifact you've deployed and choose Create Product.

   

4. Once your request to publish a product is successfully processed, you will find it in the list of available products.

   

Create a Subscription for your MCP Client

In Developer Hub, navigate to the product and open Create New Subscription for Agent. Fill in a Name and, optionally, a Short Text and Description. The field that matters most is Callback URL:

The Callback URL is the OAuth redirect_uri the platform sends the authorization code back to after the user logs in. It must match exactly what your MCP client expects.

For example:

• For MCP Inspector: http://localhost:6274/oauth/callback
• For Joule Work Desktop: http://localhost:18766/mcp-callback (validate that JWD runs on port 18766)

Leave Take me to this new subscription now checked and click Create. Developer Hub opens the subscription details page. Wait until the Credentials are generated.

You now have everything the client needs:

• The MCP Server endpoint URL (from the deployed artifact)
• The OAuth Client ID and Secret (Key and Secret from the subscription credentials)

Testing

MCP Inspector

MCP Inspector is the open-source reference client for MCP, useful for initial validation because it exposes every request, response, and token in plain view.

MCP Inspector can be installed and run locally via:

npx @modelcontextprotocol/inspector

In the Inspector UI:

1. Click Add Servers → Add manually.
2. Set Transport to streamable-http and URL to your deployed MCP Server endpoint. Click Add.
3. Click Settings for the newly added server. Under OAuth Settings set:
   • Client ID as Key from the Developer Hub subscription
   • Client Secret as Secret from the Developer Hub subscription
4. Toggle Connect. Inspector opens a browser tab, the IdP login screen appears, and after successful authentication the authorization code is exchanged for a JWT. Inspector attaches this token to every subsequent MCP request via the X-Mcp-Remote-Auth header.
5. Navigate to the Tools tab and invoke your MCP tool.

▶ Watch the MCP Inspector demo

Joule Work Desktop

Joule Work Desktop (JWD) is the SAP-native MCP-capable client. Setup is lighter because token acquisition and refresh are handled natively.

1. In JWD, add a new MCP Server connector.
2. Enter the MCP Server endpoint URL and the Client ID / Secret from the Developer Hub subscription.
3. When prompted, sign in via the IdP. JWD handles the authorization-code flow, stores the tokens, and refreshes them automatically.
4. Open a new Conversation, attach your MCP Connector to the conversation and ask e.g. to list 5 business partners.

▶ Watch the Joule Work Desktop demo

Verify Principal Propagation

Open Cloud Connector → Monitor → Most Recent Requests. Each MCP tool call should appear as a row, with the certificate subject visible in the request details and the target virtual host matching your system mapping.

References

• Building MCP Servers with SAP Integration Suite — what to design, not just how
• Principal propagation setup with SAP S/4HANA on-premise system and SAP Business Technology Platform
• SAP × Microsoft Copilot Studio MCP Gateway series, Guide 04
• SAP Help — Configuring Principal Propagation
• SAP Reference Architecture — MCP Gateway
• MCP Server with Integration Suite, expose S/4HANA Public Cloud API via OAuth2SAMLBearer

Source link