Connect Claude to SAP: choosing the server, transport and controls
As of 2026-10-18
Claude connects to SAP through the Model Context Protocol: Claude Desktop or Claude Code acts as the client, and an MCP server sits in front of the SAP system. There is no single connector. Pick the server for the job, decide whether it runs locally or remotely, and settle authentication and scope before the first tool call. For coding work, SAP's own development servers are the low-risk start. For business data, the governed route is the MCP gateway in SAP Integration Suite.
Start from the job, not the client
Coding on CAP, Fiori, UI5 or MDK: SAP's open-source development servers run on your machine and give Claude knowledge of the framework and your project model. They do not expose business data.
ABAP development: the ADT MCP server starts a local HTTP endpoint from ABAP Development Tools. Claude acts through the developer's own logged-on session, so it inherits exactly what that developer can do. Use a development system. SAP's tutorial describes the VS Code variant as experimental.
Business data in SAP applications: use SAP Integration Suite. An MCP server artifact exposes APIs as governed tools, and the MCP gateway puts them behind authentication, rate limiting and monitoring. It needs the Premium or Enhanced edition and the Integration Cell runtime.
Administration: SAP publishes a server for BTP account administration, and an Automation Pilot server where you choose which commands become tools.
The full catalogue, with maintainer and transport per server, is on our list of SAP MCP servers.
Local stdio or remote HTTP
A stdio server is started by the client as a child process on your machine. It trusts the operating-system process boundary and takes credentials from the environment, so there is no OAuth layer to build, but whatever token you put in the environment is what Claude can use. Most of SAP's development servers work this way.
A remote server speaks streamable HTTP. The MCP specification treats it as an OAuth 2.1 resource server: it publishes protected-resource metadata, and tokens are bound to one server through the resource parameter. The server must not accept tokens issued for someone else. This is the shape for anything shared by a team, and it is what the Integration Suite gateway and the LeanIX hosted endpoint use.
The protocol revision of 28 July 2026 made it stateless and deprecated roots, sampling and logging. Tutorials from 2025 may not match current clients.
Authentication and the user's identity
The question to settle first is whose authority the call carries. With an Integration Suite MCP server, the client obtains a token from the BTP subaccount's identity provider, the gateway validates it and checks the invoke role, and a destination forwards the identity. For S/4HANA on-premise or private cloud, that destination can use principal propagation through Cloud Connector. For S/4HANA Cloud Public Edition, a SAML bearer assertion is used instead.
The design to avoid is one shared technical user behind the server: every action then looks like the same person, and the per-user audit trail is lost. The ADT server is the opposite case, with no separate authorisation step at all: Claude simply has the developer's rights.
The LeanIX endpoint applies role-based permissions to queries. The community SAC server uses OAuth client credentials, which is machine-to-machine rather than per-user.
Check SAP's API policy before connecting business APIs
SAP's API policy, in the version we reviewed, restricts the use of SAP APIs by systems that plan and execute sequences of API calls, except through SAP-endorsed pathways. Trade-press analysis lists the Integration Suite MCP gateway and SAP-provided servers among them. A home-made MCP wrapper over an SAP application API is technically quick but sits outside that. Have the legal and licensing owner read the policy before you build, and do not assume a price for agentic API access: SAP had not published one.
Governance before production
Start read-only. Several servers offer it as a mode, and a community HANA server blocks data-changing statements unless you enable them. Enable writes per tool, not per server.
Name an owner for each server, because tools are an interface contract. Keep the client allow-list under control: for IDE agents, SAP's security guidance puts responsibility for extra third-party servers on the user. Log calls at the gateway, and test with a sandbox tenant first. A server is not a security boundary; it defines how tools are called, not who may call them.
Example: a remote server for market data
A remote server needs no SAP system access at all when the question is about the market. Our own server is a read-only remote MCP endpoint at https://analyticslegends.ai/mcp with 22 tools covering firms, SAP customers, day-rate benchmarks, opportunities, news, concepts and studies. Fourteen tools are public and need no key; the others need a subscriber key sent as a bearer token. In Claude Code you add it as an HTTP server pointing at that URL. Its answers carry citation URLs, and personal data of individuals is not served at any tier.
What we cannot assert
Click-by-click client configuration for each server is not in our sources and differs by version. SAP has not published commercial terms for agentic API access.
Frequently asked
Can Claude connect directly to S/4HANA?
Only through a server. Options in our sources are the Integration Suite MCP gateway, the AWS for SAP server (OData, with allow-listing and optional writes) or a community OData or RFC server. Check SAP's API policy and the identity model first.
Does Claude Desktop or Claude Code matter for the choice?
For SAP, the server decides the risk, not the client. Both are MCP clients and can use local stdio servers and remote HTTP servers. Claude Code suits the development servers; either works for remote ones.
Is there an official SAP server for Claude?
SAP's servers are client-neutral. SAP's documentation for the CAP and UI5 servers lists Claude Code among supported clients, and the ADT server accepts any MCP-capable agent on the developer's machine.
What should I check before production?
Authentication (per-user, not shared), read versus write scope, rate limits, audit logging, a named owner, and SAP's API policy. Start in a sandbox tenant.
Engage the editor
This guide is written by Cédric Mary, SAP AI & Analytics Architect & Team Lead. 27 years of SAP — Datasphere, Business Data Cloud, SAC Planning, Joule. Freelance or permanent · Hybrid / remote · Anywhere in EMEA. Available from 19 October 2026.
What this page is built on
- MCP — Model Context Protocol in SAP (mechanics)
- MCP for SAP — Adoption & Integration Strategy
- Joule for Developers & SAP MCP Servers — Agentic IDEs (VS Code, Eclipse, Claude Code, Cursor, Cline)
- MCP Authorization — OAuth 2.0 + Tier-Based API Gating
- MCP stdio Transport — For Claude Desktop, Claude Code, Local Agents
- MCP Streaming HTTP Transport — For Production Multi-Tenant Deployments
- SAP Developers — Integration Suite MCP gateway tutorial
- SAP Developers — ADT MCP server tools
- SAP Help — SAP LeanIX MCP server
External sources
- SAP Developers — Integration Suite MCP gateway tutorial
- SAP Developers — ADT MCP server tools
- SAP Help — SAP LeanIX MCP server
- Model Context Protocol — specification changelog, revision 2026-07-28
- Model Context Protocol — Authorization (2026-07-28)
- MCP blog — MCP joins the Agentic AI Foundation (9 Dec 2025)
Read next
- SAP MCP server for SAP AI & analytics data
- SAP MCP servers list: what exists, who maintains it, what it does
- MCP Authorization — OAuth 2.0 + Tier-Based API Gating
- MCP stdio Transport — For Claude Desktop, Claude Code, Local Agents
- MCP Streaming HTTP Transport — For Production Multi-Tenant Deployments
Guides that answer with this page
These guides cite this page as one of the sources their answer rests on.