SAP ECC MCP server: connect AI agents to ECC 6.0

What is an MCP server for SAP ECC?

An MCP server for SAP ECC exposes selected functions of your ECC 6.0 system to AI assistants as clearly defined tools, for example “read order status” or “show a customer’s open items”. The AI assistant speaks the open Model Context Protocol, and the server translates each tool call into a call to an ECC interface: an OData service via SAP Gateway, a BAPI via RFC, or a custom function module.

Technically, this is quite feasible with ECC. The real work lies elsewhere: Which interfaces may an AI agent use under the SAP API Policy at all, how do you preserve each user’s permissions, and how do you build so that the investment survives the migration to S/4HANA? That is what this page is about. The basics of SAP and MCP in general are in the guide to MCP servers for SAP, and the comparison with other ERP systems is under MCP servers for ERP systems.

• SAP ERP 6.0 / ECC
• OData via SAP Gateway
• BAPI and RFC
• IDocs
• Custom Z developments

Which interfaces does SAP ECC 6.0 offer for AI agents?

ECC 6.0 offers four ways for an MCP server to read data or trigger processes: OData services via SAP Gateway, BAPIs and other RFC-enabled function modules, IDocs for asynchronous document exchange, and customer-specific Z interfaces. They differ widely in how well they suit AI agents.

OData via SAP Gateway. SAP Gateway exposes ABAP functions as REST-style OData services. According to SAP, the Gateway component SAP_GWFND is included in the standard from SAP NetWeaver 7.40 and combines the scope of the earlier add-ons IW_FND, GW_CORE and IW_BEP. SAP distinguishes two setups: embedded in the ECC system, or as a central hub, which can also sit in a DMZ and keeps attacks away from the backend (SAP Help: Deployment Options). For MCP tools, OData is the most convenient entry point: HTTP, JSON, cleanly filterable, and easy to combine with gateways and API management.

BAPI and RFC. BAPIs are the classic methods on business objects that SAP intends for external use, callable via RFC. Many ECC processes can only be reached here with their validation logic intact. For an MCP server, this means it needs an RFC library and a network connection to the gateway port of the SAP system, or a BAPI is wrapped in an OData service that calls it internally.

IDocs. IDocs transport documents asynchronously between systems, such as purchase orders or delivery advices. They do not suit interactive AI questions (“Where is order 4711?”) because no direct response comes back. They make sense where an agent prepares a transaction, a person approves it, and an IDoc then brings the document into the system the usual way.

Custom Z developments. Almost every ECC system has its own OData services, function modules and CDS views in the customer namespace. They are often the only way to reach logic that exists only in your system. What the SAP API Policy says about them is covered further below.

Our rule of thumb: one tool, one business transaction, one interface. Tools such as “query OData” or “read table X” look flexible, but they do exactly what SAP restricts in the API Policy, and they are hard to explain to auditors and the works council.

How long will SAP ECC still be maintained, and what does that mean for AI projects?

On 4 February 2020, SAP announced that it would keep the core applications of SAP Business Suite 7, which include SAP ERP 6.0, in mainstream maintenance until the end of 2027. After that, optional extended maintenance is available at an additional charge from early 2028 to the end of 2030; customers who do not choose it move to customer-specific maintenance (SAP News, 4 February 2020).

For companies with very complex landscapes, SAP additionally announced the “SAP ERP, private edition, transition option” on 4 February 2025: a cloud subscription within RISE with SAP, usable from 2031 to 2033, provided the systems have been moved to SAP ERP, private edition and run on SAP HANA before the end of 2030 (SAP News, 4 February 2025).

What this means for an AI project on ECC: An MCP server on ECC is worthwhile if it delivers value now and the work does not disappear with the ECC system. That is why, with ECC, we invest little in system-specific depth and a lot in a clean tool layer: tools named after business tasks, clear inputs and outputs, and a concept for authorizations and audit logs. This layer stays; only the adapters beneath it change (see Migration).

What does the SAP API Policy say about ECC and custom Z interfaces?

The SAP API Policy also applies to ECC: according to the SAP FAQ, it is part of the documentation for all cloud solutions and the entire on-premise portfolio (FAQ, question 1). For AI agents, the key provision is section 2.2.2, which prohibits API use by AI systems that plan or select calls themselves, outside paths recognised by SAP. The detailed assessment, with the quotation and the recognised paths, is in the section SAP API Policy 2026 of our SAP guide. Here we cover the questions that additionally arise with ECC.

Published APIs on ECC. Section 1.1 of the Policy defines Published APIs as everything listed in the SAP Business Accelerator Hub or identified in the product-specific documentation. For ECC, this means in practice: check for every BAPI, every standard OData service and every IDoc type whether it is documented for your release. According to the FAQ (question 23), community blogs and forum posts do not confer Published status.

Custom Z interfaces. Section 1.2 expressly allows customers in private cloud and on-premise systems to use their own ABAP interfaces. The FAQ clarifies this in question 27, which sets out which interfaces count as “custom-developed” and where the line is drawn:

In plain terms: your Z interface is not a problem in itself. But it is not a detour either. According to the FAQ, a Z-OData service whose only purpose is to give an AI agent free access outside a recognised path falls squarely under the restriction. And whatever the Z interface calls internally must itself follow the rules of the Policy.

What else the FAQ says about ECC landscapes:

• ODP-RFC is, according to SAP Note 3255746, not permitted for customer and third-party applications on ABAP systems with PI_BASIS, SAP BW or BW/4HANA (FAQ, questions 22 and 23). It is not a route for extracting data to AI or analytics platforms.
• ADT interfaces (ABAP Development Tools) are, according to question 33, intended for development, not for agentic AI processes on business data.
• An internal API inventory with namespace, interface type, purpose and responsible team is what SAP recommends for custom interfaces (question 28). For an MCP project, this is the working basis anyway.
• Rule-based processes without LLM planning do not fall under section 2.2.2, according to question 40, but they are subject to the remaining rules.

Who builds MCP servers for heavily customised ECC systems?

Heavily customised ECC systems need a team that can read custom ABAP developments and also has command of MCP, authorizations and AI security. Standard connectors usually fail there not because of the technology but because the decisive logic sits in Z tables, user exits and custom developments that no off-the-shelf product knows.

This is how we proceed with a lot of custom code:

1. Collect questions, not tables. We start with the questions your team answers today by phone, Excel export or SE16 extract. The tools are derived from those.
2. Inventory the existing interfaces. Which standard BAPIs and OData services cover the question? Which Z modules already exist, who maintains them, and which SAP objects do they access? The Cloud Readiness Check in the ABAP Test Cockpit shows where custom developments access SAP objects that are not released (FAQ, question 30).
3. Encapsulate business logic in ABAP rather than rebuilding it in the MCP server. If a metric is only correct with your Z logic, it belongs in a dedicated function module or OData service with a fixed input and output format. The MCP server only calls it.
4. Every Z interface gets a purpose. Justified by the business, with upper limits and without generic access. That keeps it explainable under FAQ 27 as well.
5. Test in the quality assurance system with a realistic data set and the business department before anything goes live.

Which architecture options exist, with and without SAP BTP?

For on-premise ECC there are three viable architecture options: via SAP BTP with the Cloud Connector and the MCP Gateway of the Integration Suite; without BTP, using your own network components such as SAP Web Dispatcher, Azure API Management or Microsoft’s On-Premises Data Gateway; or rule-based, without AI planning in the access.

Two things often get mixed up in conversations. First: the Cloud Connector belongs to the BTP. Anyone who says “without BTP” needs a different network path. Second: a network path alone does not make a recognised path under the Policy. Azure API Management or a Web Dispatcher solve reachability, throttling and protocol, but the policy question for the MCP server behind them remains. In section 3, the Policy expressly prohibits circumventing its controls via intermediary services, proxies or gateways.

Whose permissions does the AI agent use to access ECC?

The AI agent should access ECC with the permissions of the person asking, not with a shared technical user. Only then does each person see in the AI response exactly what they would be allowed to see in ECC, and only then does the audit log show who queried what.

Why the shared user is tempting and still wrong. A technical RFC or service user is quickly set up. After that, everyone who uses the assistant sees everything that account can see: salaries, conditions, blocked vendors. ECC’s authorization check then leads nowhere. For pure test systems with anonymised data, a shared user can be enough; in production, it cannot.

Principal propagation. The clean approach is called principal propagation: the identity of the signed-in user is passed through to the SAP system and mapped there to an ECC user. Via the BTP, the Cloud Connector handles this, passing on the identity through a short-lived X.509 certificate or Kerberos (SAP Help: Principal Propagation). Without BTP, Microsoft points to published policy building blocks for principal propagation to SAP ECC or S/4HANA for Azure API Management.

What the server adds. For custom MCP servers, the SAP Architecture Center requires a token exchange per RFC 8693 with agent and user context instead of a passed-through user token, no long-lived credentials, and an audit log of every tool call (SAP Architecture Center). In ECC itself, roles should be cut narrowly: authorizations for exactly the RFC modules and OData services the tools need, and no more.

• Permissions of the person askingPrincipal propagation instead of a shared user as soon as real data is involved.
• Narrowly cut rolesOnly the modules and services of the approved tools, no table display, no development rights.
• Read firstWrite tools do not exist in the read-only server at all, rather than just being blocked.
• Audit log per callUser, tool, parameters (personal data masked), target interface, status, runtime.

How the MCP server itself is secured is covered in the guide MCP server: security and GDPR. Why SAP error messages and free-text fields should not go into the model unfiltered is explained in the guide on prompt injection.

How does an ECC MCP server survive the migration to S/4HANA?

An ECC MCP server survives the migration if its tools are organised around business transactions rather than ECC interfaces. The AI assistant then only knows “read order status” with fixed fields. Whether an ECC BAPI or an S/4HANA API from the Business Accelerator Hub answers behind it is decided by a replaceable adapter.

In concrete terms, this means for the setup:

• Stable tool contract: Name, description, inputs and output fields are worded in business terms and versioned. This also matches the SAP Architecture Center’s requirement for versioned tool descriptions.
• One adapter per system: For each tool, an ECC adapter today and an S/4HANA adapter tomorrow. Both deliver the same output format.
• Treat Z logic deliberately: Whatever can only be done in ECC through custom development goes on the list for the migration. According to the SAP FAQ (question 10), the S/4HANA Simplification Item Catalog and the report /SDF/RC_START_CHECK show which objects in use are dropped or changed in S/4HANA.
• Audit log as a migration aid: The call log shows which questions your team really asks. That is a solid basis for deciding which analyses and interfaces must be in place first in S/4HANA.

This turns the MCP server from a stopgap project into part of migration planning. Your team gets used to working with the AI assistant while the ERP beneath it changes.

What does an ECC MCP project look like?

An ECC MCP project starts by settling the path and the policy question, and only then with code. We proceed in four steps:

1. Clarify: use cases, existing interfaces, architecture path, authorization concept and the question for your SAP contact, as a decision paper for IT, data protection and the works council.
2. One read-only use case: for example order and delivery status, in the quality assurance system, with the individual user’s permissions and an audit log.
3. Pilot with the business department: real questions, real feedback, then fine-tuning of tool descriptions and upper limits.
4. Expand: further tools; write operations only with an approval step by an authorised person.

We set the timeline after the AI Check. It depends mainly on approvals and authorizations, less on code.

Frequently asked questions

Is there an MCP server for SAP ECC?

Yes, ECC 6.0 can be connected via MCP. The server provides fixed tools that call OData services via SAP Gateway, BAPIs via RFC or custom Z interfaces. For AI agents, SAP itself offers the MCP Gateway of the Integration Suite as a recognised path; according to the SAP FAQ, a custom MCP server is permitted if its usage is consistent with the contract, the documentation and the API Policy.

Does ECC need SAP Gateway for an MCP server?

Not necessarily. OData via SAP Gateway is the most convenient entry point, and according to SAP the component SAP_GWFND is included in the standard from SAP NetWeaver 7.40. Alternatively, the MCP server calls BAPIs or custom function modules via RFC.

Does the SAP API Policy also apply to on-premise ECC?

Yes. According to the SAP FAQ, the API Policy is part of the documentation for the entire on-premise portfolio. For AI agents, the key provision is section 2.2.2, which restricts AI systems that plan or select API calls themselves to paths recognised by SAP.

May an AI agent use our own Z interfaces?

Under the Policy and FAQ question 27, custom interfaces in the customer namespace are not prohibited per se. However, whatever they call internally must follow the Policy, and they must not create a path for unendorsed AI agents or mass extraction. This is an assessment, not legal advice.

How long will SAP ECC still be maintained?

In 2020, SAP announced mainstream maintenance for SAP ERP 6.0 until the end of 2027, with optional extended maintenance from 2028 to the end of 2030. Which phase applies to your system depends on the release, the enhancement package and your contract; the authoritative sources are the SAP Product Availability Matrix and your maintenance contract.

Is an MCP server on ECC worthwhile shortly before the S/4HANA migration?

Yes, if the tools are organised around business transactions rather than ECC interfaces. Tool descriptions, authorization concept and audit log are then retained, and only the adapters beneath them switch to S/4HANA APIs.

Do we need SAP BTP for AI on ECC?

No. The Cloud Connector and the MCP Gateway of the Integration Suite run via the BTP. Without BTP, a custom MCP server can reach ECC through, for example, SAP Web Dispatcher, Azure API Management or Microsoft’s On-Premises Data Gateway. The policy question for the custom server then still has to be clarified.

Whose permissions does the AI agent use to access ECC?

With the permissions of the person asking. Principal propagation ensures this: via the BTP with the Cloud Connector, or without BTP through Azure API Management, for example. A shared technical user is only defensible for test systems with anonymised data.

Can the AI agent also post documents or create orders in ECC?

Technically yes, via BAPIs or OData. We nevertheless start read-only and only build write tools once the path, the policy question and the authorizations are settled, and then with an approval step by an authorised person.

Who builds MCP servers for heavily customised ECC systems?

A team that can read custom ABAP developments and has command of MCP, authorizations and AI security. We encapsulate customer-specific logic in dedicated function modules or OData services with a fixed format and call them from the MCP server.