Blog › KI
KICoding

ABAP Goes Agentic: MCP Server, VS Code, and the Price of AI Support

· David · 9 min read
ABAP Goes Agentic: MCP Server, VS Code, and the Price of AI Support

SAP bundled several announcements at Sapphire 2026 that together describe what SAP calls “the most significant step forward in ABAP AI” since the introduction of Joule for Developers: the ABAP MCP Server reaching general availability, VS Code as a second ABAP IDE, three custom code agents for S/4HANA migration, and a new pricing model. Here is what is behind the announcements technically, what they can realistically deliver — and what is still missing.

The Architecture: Language Server as Foundation

The ABAP Language Server is the technical foundation for all of this week’s announcements. It is not new — it has existed for years as the abstraction layer through which Eclipse (ABAP Development Tools) communicates with SAP backend systems. What SAP has now done: built the ABAP MCP Server on top of this foundation.

MCP stands for Model Context Protocol — an open standard developed by Anthropic that has since been adopted across a broad ecosystem of AI tools. MCP describes how AI agents interact with external systems and tools: in a structured, reliable way, without proprietary per-tool integrations. With the ABAP MCP Server, developers can use GitHub Copilot, Amazon Q, Claude Code, or any other MCP-compatible agent to perform ABAP development operations — directly from within the IDE, without SAP-specific plugin coupling. Claude Code, for example, connects to MCP servers via its configuration file; the ABAP MCP Server is just as accessible to Claude Code as to any other MCP client.

What the server exposes:

  • Read, create, update, and delete ABAP objects
  • Manage transport requests
  • Syntax checks and code analysis
  • Search across ABAP keyword documentation, DSAG development guidelines, and ABAP Style Guide
  • ABAP Feature Matrix: availability of ABAP features across releases and ABAP Cloud variants

The server is available in both Eclipse and VS Code.

A note on context: the community was here first. Marian Zeis published an ABAP MCP Server for GitHub Copilot in Eclipse in February 2026, connecting it via the official ADT endpoint. Mario Andreschak built a separate variant on GitHub. SAP is now institutionalizing and supporting what others built first — that is not a criticism, but a precise description. The speed at which the community adopted MCP for ABAP, before any official SAP product existed, is worth noting in its own right.

VS Code: Closing a 14-Year Gap

On May 29, 2026, ABAP Development Tools (ADT) for Visual Studio Code is scheduled to reach general availability — fourteen years after the ADT for Eclipse launch. VS Code is the most widely used IDE in the world, with a dense ecosystem of AI extensions. Bringing ABAP there is the logical consequence of the Language Server architecture: the IDE no longer communicates directly with the backend, but through the Language Server, which can be connected independently of the IDE.

SAP is transparent about the limitation: the initial scope focuses on SAP Fiori app development. Eclipse remains the IDE for full ABAP development until VS Code reaches feature parity. Developers working on complex backend objects, Business Objects, or deep ABAP Cloud structures remain tied to Eclipse — the Java-based IDE that has been waiting for a replacement for fourteen years and, for the foreseeable future, will not get one, as SAP stubbornly refuses to fully arrive in the 21st century.

For developers primarily writing Fiori frontend or ABAP Cloud code, VS Code is still a meaningful step forward: direct access to GitHub Copilot Agent Mode, Cursor, Claude Code, or other AI coding assistants — in the environment they already use, without the Eclipse detour.

The combination of Language Server, MCP Server, and VS Code integration produces an architecture that has been standard in other development ecosystems for years. That it is arriving for ABAP in 2026 is the real news behind the announcement.

Custom Code Agents: The Most Concrete Use Case

The Custom Code Migration (CCM) agents are the announcement with the most immediate business value. SAP S/4HANA migration projects do not fail because of missing infrastructure — a large part of their complexity lies in existing ABAP custom code: grown over years, often undocumented, tightly coupled with SAP standard objects. Understanding, adapting, and validating that code is time-consuming and expensive.

SAP plans three agents for this area:

AgentFunctionAvailability
Mass S/4 Custom Code Conversion AgentIdentify ATC findings; apply deterministic and AI-generated fixes at scaleQ2 2026
Mass Clean Core Adoption AgentIdentify clean-core ATC issues, fix them, or provide structured recommendationsLater 2026
Web Dynpro to SAP Fiori App Modernization AgentConvert legacy Web Dynpro code to modern ABAP Cloud codeLater 2026

SAP explicitly states a design principle: each agent should first understand and explain the existing code before proposing changes. That is the right approach — uncontrolled mass modifications to productive custom code would be counterproductive.

SAP cites a target of 40% efficiency gain in custom code transformation work, based on its own early evaluations. No independent benchmarks exist. That is not an accusation — external evaluations take time and real production deployments. But project budgets should treat this number as SAP’s own internal measure, not an external validation.

Even at a significantly lower success rate, the case for using these agents in migration projects with large custom code volumes is sound: repetitive, rule-based analysis at scale is precisely the use case where AI performs best in enterprise environments — with a human in the final review loop.

Platform Reach: Older Releases Gain Access

One of the most practically relevant announcements is not about new capabilities, but about who can access them. SAP Joule for Developers, ABAP AI capabilities, will become available for SAP S/4HANA Cloud Private Edition in Q2 2026 — covering all releases from 2021 onwards.

Until now, ABAP AI was tied to more recent releases. Customers running older releases for licensing or stability reasons were excluded. The technical basis for this expansion is a hub service on SAP BTP that combines authentication, license management, SAP BTP AI Core, and ABAP-specific business logic. The hub connects directly to the developer’s IDE, making it largely independent of the ABAP backend release.

What this does not change: purely on-premise systems without cloud connectivity remain excluded. Joule is tied to RISE or GROW contracts. That is a structural boundary this announcement does not move — and one that creates a tangible competitive disadvantage. Vendors like Salesforce deliver AI capabilities directly into the existing install base, without migration as a prerequisite. SAP customers running on-premise without a RISE migration on the roadmap get nothing from this announcement package — while alternatives exist that do not ask where their systems run.

The Pricing Model: Transparent — With Caveats for Agentic Workloads

The free period ends in Q2 2026. SAP is introducing consumption-based pricing for SAP Joule for Developers, ABAP AI capabilities, billed in AI Units.

The principle is straightforward: pay for what you use, not a flat fee for a function you rarely invoke. Activation runs through SAP for Me; user assignment through Cloud Identity Services. SAP promises real-time consumption monitoring.

The challenge lies in the nature of agentic workloads: an agent performing large-scale custom code analysis and transformation consumes AI Units at a rate that depends on codebase size, iteration depth, and the complexity of findings — factors that are structurally difficult to estimate in advance. Consumption pricing is plannable when usage is plannable. With agentic processes, that is harder by design.

Current market data adds further context: only around 3% of SAP customers have Joule in production use. The primary factor: the dependency on RISE or GROW contracts, which excludes on-premise customers entirely. The new pricing model and expanded platform availability address part of this barrier — but not its root.

Assessment: What SAP Gets Right — And What Is Still Missing

Choosing MCP as an open standard is the right strategic call. Instead of a proprietary SAP-Joule integration that locks developers into a closed system, an open interface emerges: agent choice sits with the developer. That makes the ABAP platform more attractive long-term — including for teams primarily working with GitHub Copilot, Claude Code, or other tools.

The Language Server architecture could have arrived earlier. Using it now as the foundation for MCP integration and IDE independence is the right application of the right tool.

What is missing:

A governance framework for autonomous agents in productive ERP systems. Agents that write custom code into transport requests, rebuild Fiori apps, or mass-apply ATC fixes are making decisions in an environment with significant consequences. The EU AI Act provides for formal risk assessments for autonomous systems in certain categories. SAP has not addressed this in its announcements so far.

Independent benchmark data. The 40% efficiency gain is SAP’s own early evaluation. That is a starting point for internal planning, not the basis for external budget decisions. Customers planning migration projects on this basis should run their own pilots before scaling.

A complete offering for on-premise. The BTP hub architecture partially solves the problem for Private Edition customers on releases from 2021 onwards. For systems without BTP connectivity or on older releases, ABAP AI remains out of reach — and this continues to be the biggest structural weakness in SAP’s AI strategy. Joule will remain a marginal system, artificially constrained by licensing decisions dressed up as go-to-market strategy.

The Sapphire 2026 announcements deliver concrete deliverables with Q2 dates — not promises without a timeline. The ABAP MCP Server gives the community an official, supported interface for something it had already built. VS Code ADT is a step that was overdue by fourteen years. And the Custom Code Migration agents address the most expensive problem in S/4HANA projects with a tool that is genuinely well-suited for the task.

What September 2026 will show in real usage numbers and billing data is the next meaningful data point in this story.

Sources

David
David
AI, Apple Silicon, coding experiments, SwiftUI, and attitude.
Read more