EngineeringArchitecture & Modernization
AWS for SAP MCP Server Brings Decoupled Agent Architecture to Enterprise ERP
AWS just shipped a container that turns SAP's OData APIs into first-class tools for AI agents, deployed on a managed runtime with session isolation and OAuth 2.0 out of the box. For Bulgarian teams running SAP workloads, this is the first production-grade path to agentic automation without custom integration code.
In Brief
AWS released the AWS for SAP MCP Server on Amazon Bedrock AgentCore, enabling AI agents to discover, read, and write SAP business data through standardized protocols. The server bridges Model Context Protocol (MCP) clients to SAP’s OData APIs, covering finance, procurement, logistics, and HR processes. For Bulgarian teams running SAP workloads or building agentic systems, this is the first production-grade path to connecting autonomous agents with ERP data without custom integration code.
The Decoupling Problem Nobody Wanted to Solve
Enterprise AI agents have a dirty secret: most of them are tightly coupled to the systems they interact with. Every new data source means new integration code. Every API change means agent updates. Every vendor switch means starting over.
The AWS for SAP MCP Server attacks this problem by adopting two open standards. The Model Context Protocol, open-sourced by Anthropic in 2024, standardizes how agents connect to external tools and data sources. The Agent-to-Agent protocol (A2A), introduced by Google in April 2025, enables autonomous collaboration between independent agents across different frameworks and vendors.
The result is a decoupled architecture where agents and tools can be developed, deployed, and updated independently. An agent built with Amazon Quick can discover the same SAP tools as one built with SAP Joule Studio. A procurement workflow orchestrated through A2A can call the same MCP server as a finance exception handler.
What the Server Actually Does
The AWS for SAP MCP Server exposes four core capabilities through MCP tools:
Catalog Discovery: Agents can query what SAP OData services are available at runtime. The server supports two modes: remote catalog (live connection to SAP’s OData catalog service) and local catalog (a configuration file in Amazon S3 for API management scenarios where native catalogs are unavailable).
CRUD Operations: Create, read, update, and delete SAP business objects. Sales orders, purchase orders, materials, finance documents. The current release supports OData V2, which covers SAP S/4HANA and SAP ECC.
Service Hints: Beyond OData metadata, the server provides contextual guidance for specific services. Known issues, recommended workarounds, service-specific quirks. Hints are stored as JSON in S3 and can be defined globally or targeted by pattern.
Identity Management: AgentCore Identity handles both inbound (MCP clients to server) and outbound (server to SAP) authentication. Separate trust boundaries, OAuth 2.0, enterprise identity provider integration.
Network Architecture for the Paranoid
The server runs inside your VPC on Amazon Bedrock AgentCore Runtime. Tool calls stay within your private network boundary. The connectivity options depend on where your SAP system lives:
For SAP BTP API Management, the server connects over HTTPS with OAuth 2.0. Traffic egresses to the internet but is secured with TLS.
For SAP cloud ERP private (formerly RISE with SAP) on AWS, the server connects via VPC Peering or AWS Transit Gateway. Traffic stays on the AWS backbone.
For SAP ERP in your own AWS account, the server deploys in the same VPC or connects across VPCs. All traffic stays within AWS.
The paranoid will note that the first option involves internet egress. The pragmatic will note that SAP BTP API Management is where most enterprises expose their OData APIs anyway.
The OData Foundation
SAP standardized on OData as its API protocol across the entire product portfolio. Hundreds of documented services span finance, procurement, logistics, and human capital management. Custom OData APIs built through SAP Gateway support clean core extensions, keeping systems upgrade-safe while enabling agentic workflows outside the core.
This is not a new protocol. OData V2 has been around since 2007. What is new is treating these APIs as first-class MCP tools that any compliant agent can discover and act on without custom integration code.
What This Means for Bulgaria
Bulgarian teams running SAP workloads on AWS now have a production path to agentic automation without building custom connectors. The practical implications:
For DevOps teams: The server ships as a container image at no cost. Deployment on AgentCore Runtime means no infrastructure management for session isolation or identity. If you are already running SAP on AWS, the network architecture is straightforward.
For architects evaluating agentic systems: The MCP and A2A standards are worth understanding now. Anthropic and Google are not the only players. AWS adoption signals that these protocols are moving from experimental to enterprise-grade.
For teams with SAP BTP investments: The local catalog mode means you can expose exactly which OData services agents can access, controlled through S3 configuration. This is the governance layer that was missing from earlier agentic approaches.
For compliance leads: AgentCore Identity’s dual-layer authentication (inbound and outbound) maintains separate trust boundaries. Every tool call is logged across different log levels. This is the audit trail that regulators will eventually ask for.
The Catch
The current release supports OData V2 only. OData V4, which SAP has been pushing for newer services, is not yet supported. Teams with mixed V2/V4 landscapes will need to wait or maintain parallel integration paths.
The server also requires SAP BTP API Management for the recommended connectivity pattern. Teams running SAP without BTP will need to evaluate the VPC Peering or Transit Gateway options, which add network complexity.
