SAP's agent connectivity components

SAP has built (and is still building) several components around MCP and A2A. They are easy to confuse because the names are similar and their maturity differs. This lesson maps each one: what it does, which direction traffic flows, and what SAP's own documentation says about its status as of October 2026.

Joule as an A2A client: bring your own agent

The most established A2A path runs outbound. In Joule's documentation for code-based agents, Joule prepares an A2A message/send request with the user's utterance, following A2A version 0.3.0 over JSON-RPC, and calls your agent. Only text messages are supported. For synchronous calls Joule expects a response within 60 seconds; for long-running tasks it supports push notifications to a Joule webhook, which requires an SAP Cloud Identity Services (IAS) App2App trust between Joule and your agent server. Context and task IDs can be carried across turns for multi-step conversations.

Agent Gateway: external agents call Joule Agents

The inbound direction is the Agent Gateway. SAP's Architecture Center describes it as an SAP-managed, publicly reachable endpoint that exposes Joule Agents over A2A 0.3.0 with HTTP+JSON transport. Callers authenticate with IAS App2App tokens that carry a named user context, access is role-based, interactions are logged for audit through SAP Cloud ALM, and responses come back either as a synchronous task confirmation or through a callback URL. The page (updated 14 October 2026) carries a disclaimer that parts of this architecture are not yet generally available, in particular bidirectional communication with third-party and self-hosted agents through the Agent Gateway. Teach and design that path as a target, not as something to rely on today. SAP uses the name for one component with two roles: the Joule Studio glossary describes the Agent Gateway as the governed access layer through which deployed agents call SAP back ends as MCP tools, while this page and SAP's Cross-Domain Agents guide describe it as the inbound A2A entry point for external agents.

MCP Gateway in SAP Integration Suite

The MCP Gateway is how SAP Integration Suite exposes enterprise capabilities to agents as MCP. In the documentation, an MCP Server is a first-class artifact: you create it in an integration package, configure its tools, resources, prompts and policies, deploy it to the Integration Cell runtime, publish it through Developer Hub, and consumers subscribe to the product to get scoped credentials. An analytics dashboard shows agent calls, errors and response times. You can create an MCP server from four sources:

• An API artifact deployed on Integration Cell.
• Any HTTP endpoint, described by an OpenAPI specification.
• An RFC-based back end, such as SAP S/4HANA or SAP ECC, by modeling RFC operations as tools.
• A remote MCP server (it must support Streamable HTTP), so Integration Suite acts as a managed proxy and governance layer in front of it.

Two practical notes. Availability depends on your Integration Suite service plan (SAP Note 2903776), and SAP's architecture guidance warns not to assume the same MCP support on Edge Integration Cell; the documented runtime is Integration Cell in the cloud. Every MCP server has mandatory Authentication and Authorization policies, and only OAuth-based authentication is supported: tokens come from SAP's default XSUAA or, with External OAuth (OIDC), from an OIDC-compliant identity provider such as SAP Cloud Identity Services, Okta, Auth0 or Microsoft Entra ID. Quota, Surge Protection and IP Filter policies add traffic control; payload protection stays on the source API artifact.

SAP-provided MCP servers

"SAP MCP server" means different things in different conversations, so be precise: