AWS Builder Center

Connect Kiro to SAP to document and generate ABAP code

This post shows SAP technical teams how to use Kiro with the ABAP Accelerator MCP and SDK ABAP Knowledge MCP to read source code from SAP systems via ADT, automate ABAP documentation at scale, generate ALV reports, run ATC quality checks, and analyze ECC-to-S/4HANA migration readiness — all from a single IDE.

Senior Specialist SA, GenAI/ML

Introduction

If you work with ABAP code, Kiro gives you direct access to the source code of your SAP system through ADT (ABAP Development Tools). Kiro is the AWS agentic IDE, a development environment where an AI agent reads your code, plans the changes, and runs development actions under your supervision.
In this post we show how to connect Kiro to SAP through MCP to document, generate, and validate ABAP code directly from the IDE, and how to apply Kiro's capabilities (Specs, Hooks, and Steering) to real-world scenarios for technical teams that develop in SAP.
Three capabilities set Kiro apart from an autocomplete assistant. Specs enable iterative design with full traceability, where the flow goes from requirements to design, then to tasks, and finally to implementation, keeping the thread from start to finish. Hooks automate flows when you save a file, commit, or finish a task, with no manual intervention. Steering encodes the team's quality standards (code conventions, modularization rules, and best practices) and applies them actively in every interaction with the agent.
On top of these three capabilities, Kiro adds native support for MCP (Model Context Protocol), the standard that connects the agent to external systems. This is where SAP enters the equation.
Kiro operates with supervised autonomy: the agent proposes, runs, and validates, but you stay in control at all times. It is available for free at kiro.dev .

The problem: SAP without context

Those of us who work with ABAP code and use a generic AI-powered IDE already know the limitation: the agent knows nothing about our system. It does not know our Z programs, our BW transformations, our custom tables, or the business logic that has accumulated for years without documentation.
In the day-to-day of an SAP team, three recurring problems appear. The first is missing documentation: Z programs written years ago, with no comments or functional description, where only the person who wrote them knows what they do (if they are still with the company). The second is logic embedded in BW transformations, with start, end, and field-mapping routines in ABAP code that is not visible from the system's graphical interface; whoever inherits those routines faces weeks of code review. The third is migration without visibility: moving from ECC to S/4HANA or migrating BW requires inventorying complex logic scattered across hundreds of objects.
We can always download that code and paste it into an AI to have it explain what the code does. But that leaves us as intermediaries: we copy, paste, process, and discard. A generic AI agent responds with general ABAP patterns, which is useful for learning but insufficient to produce real work on our system.
And let's be honest: there is nothing worse than going back to code you wrote years ago. Or maybe there is: taking over someone else's ABAP code.
The leap Kiro proposes is different. With Kiro and the ABAP Accelerator, the agent does not just explain the snippet you pasted. It generates documentation at multiple levels of depth and understands the dependencies between programs, between functions, and between tables. It does not produce an isolated explanation, but a map of the system. You go from intermediary to having a collaborator that understands the full context of your SAP.

MCP: the bridge between Kiro and SAP

MCP (Model Context Protocol) is an open standard created by Anthropic in 2024. It defines how an AI agent connects to external systems to obtain real-time context.
The following table compares the agent's behavior with and without MCP:
Without MCPWith MCP
Generic agent with training knowledgeContextualized agent with access to the SAP system
Knows nothing about your Z codeReads source code directly from SAP
Generic responsesResponses based on your real context
Cannot validate against your systemRuns ATC, syntax check, and unit tests live
MCP works as a standard protocol: any compatible agent can connect to any system that exposes an MCP server. Kiro supports it natively.

The MCP servers for technical SAP teams

For ABAP development there are two relevant MCP servers, which cover complementary needs.
The ABAP Accelerator  gives access to SAP source code through ADT. It lets you document, create, test, and transform ABAP code directly from Kiro, because the agent reads the code in real time from the SAP system and does not work with local files or assumptions. It runs locally (with Python or Docker) or on Amazon Elastic Container Service (Amazon ECS) with AWS Fargate for full teams. It connects to SAP through the ADT REST protocol over HTTP/HTTPS and has no cost, since the Docker image is downloadable. In local mode it is extensible: you can ask Kiro to build new tools tailored to your use case, such as tracing logic in SAP BW transformations (start and end routines, mapping rules, and dependencies between objects), generated as a new tool inside your local MCP.
The SDK ABAP Knowledge is the knowledge base of the AWS SDK for SAP ABAP . It generates syntactically correct ABAP code to integrate AWS services such as Amazon Simple Storage Service (Amazon S3), Amazon Bedrock, and Amazon DynamoDB, among more than 200 services, from ABAP code. To understand how it integrates with agentic IDEs, we recommend reading Extend agentic IDEs with AWS SDK for SAP ABAP documentation . It is a public endpoint that you only add to mcp.json (the exact URL is in Step 2), it requires no authentication or installation, it updates daily in sync with SDK releases, and it exposes more than 80,000 pages of ABAP documentation that the agent queries in real time.

Specs, Hooks, and Steering applied to SAP

Before getting into the use cases, it helps to see how the three capabilities that set Kiro apart take shape in SAP. Each one is configured with straightforward files inside the project and applies to concrete ABAP development tasks.

Steering: encoding the team's ABAP standard

Steering files are markdown files that live in .kiro/steering/ and accompany every interaction with the agent. They serve to set code conventions, business rules, and best practices. A Steering file can be included always, conditionally based on the open file, or manually.
The following example defines an ABAP standard that the agent respects when generating or modifying code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
---
inclusion: always
---

# Team ABAP standard

## Naming
- Local variables prefixed with `lv_`, internal tables with `lt_`, structures with `ls_`.
- Custom classes prefixed with `ZCL_`, interfaces with `ZIF_`.

## Modularization
- Methods of at most 50 lines. If it grows beyond that, split it.
- Prefer ABAP Objects classes over programs with legacy includes.

## Comments
- Each method has a header with purpose, parameters, and author.
- Document the business logic, not the syntax.
Once saved, the agent follows these rules across the whole project without having to repeat them in every prompt.

Hooks: automating quality without manual intervention

Hooks run an agent action when an event occurs in the IDE. For an SAP team, this lets you trigger automatic validations when an ABAP file is saved or when a task finishes.
The following Hook runs an ATC review every time an .abap file is saved:
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "Validate ABAP on save",
"version": "1.0.0",
"when": {
"type": "fileEdited",
"patterns": ["*.abap"]
},
"then": {
"type": "askAgent",
"prompt": "Run ATC and syntax check on the saved file and fix the Error-severity findings."
}
}
You can also automate at the close of each Spec task, using the postTaskExecution event, so the agent generates or runs the ABAP unit tests before marking the task as completed.

Specs: from requirement to implementation with traceability

A Spec structures the work into three documents inside .kiro/specs/: requirements.md captures what is needed, design.md defines how it is implemented, and tasks.md breaks the work into executable tasks. The agent walks that flow keeping traceability from start to finish.
To create a Spec for mass documentation of Z programs, you describe the goal to Kiro in natural language and the agent proposes the requirements first. An excerpt from requirements.md might look like this:
1
2
3
4
5
6
7
8
9
10
# Requirements: documentation of Z programs in the MM module

## Requirement 1: inventory
AS a migration team
I WANT an inventory of the Z programs in the ZMM package
SO THAT I can prioritize documentation by complexity.

### Acceptance criteria
1. WHEN the task runs THEN all Z programs in the package are listed with lines of code and dependencies.
2. WHEN a program exceeds 1,000 lines THEN it is flagged as high complexity.
After your approval, Kiro generates the design.md with the output format and nesting levels, and then the tasks.md with one task per program. From there, the agent runs the tasks one by one and produces consistent documentation for the entire package.

Concrete use cases

The capabilities above make sense when applied to real SAP team problems. Next, we walk through four scenarios where Kiro and the SAP MCP servers deliver immediate value: documentation of Z programs, ALV generation, code quality sweeps, and migration analysis.

Automatic documentation of Z programs

This is probably the use case that excites us the most, because it tackles a pain almost everyone has lived: going back to code we wrote years ago or, worse, inheriting someone else's code.
Documenting Z programs is not about pointing at the system and saying "document everything." There is an iterative methodology that works and that we want to share, organized in three phases.
Phase 1, vibe coding: build the documentation framework. Before documenting a single program, you have to define what to document and why. This is done conversationally with Kiro. First, you set the goal, because documenting to migrate within SAP (from ECC to S/4HANA, with a clean core focus) is not the same as documenting to migrate out of SAP and rewrite in another language. Then you identify the critical data; a good practice is to ask Kiro to search the internet for what is most relevant to document in an ABAP program and then personalize it with the customer's context, such as the tables used, the lines of code, and the commented lines. You also define the nesting levels worth exploring, since a program references functions, tables, and other programs, and it is not always worth going all the way down. Finally, you choose the output format: markdown, table, Word, or integration with the customer's existing documentation system.
Phase 2, iteration: validate and adjust. With the framework defined, we test it against programs of different complexity levels: a basic one, a medium one, and one with many dependencies. Each iteration adjusts the process and the output until the result is consistent and useful.
Phase 3, spec-driven: mass documentation. Once the framework is validated, we build a Spec in Kiro (requirements, design, and tasks) to document entire packages of Z programs. The grouping depends on what best serves the customer, whether by SAP module, by development package, or by responsible team. The agent runs the tasks one by one and generates consistent documentation for the whole group.
📄 Real example: in FRAMEWORK_DOCUMENTACION_ABAP_Z_AWS.md we share a complete framework built with Kiro. It includes the 12 sections we use to document Z programs with a focus on migration and modernization on AWS, from identification and code metrics, through ABAP Cloud Readiness analysis, to the target architecture on AWS with a phased action plan. Example output: in ZORDERTOCASH.md we show the result of applying that framework to a real program. The original source code is in ZORDERTOCASH_source.md , so you can see firsthand the input and the output of the process.
The following diagram summarizes the three phases of the documentation methodology:
Documentation methodology in 3 phases
Documentation methodology in 3 phases

Generating ALVs with a semantic layer

SAP tables have names that are not easy to understand. To get output that is readable for the business, you have to join multiple tables and build a semantic layer on top, which requires deep knowledge of the SAP data model.
With Kiro, that process changes. Instead of building the ALV table by table, we ask the agent in natural language for what we need:
"Help me generate an ALV where I can see the procurement cycle end-to-end: from purchase requisition, purchase order, goods/services receipt, to payment. With descriptive columns, not technical names."
With access to the system through the ABAP Accelerator, Kiro identifies the tables involved (EBAN, EKKO, EKPO, MSEG, BKPF, BSEG) and builds the JOINs. It then generates columns with readable descriptions and produces the complete ABAP program.
The following screenshots show the ALV generation in Kiro and its final execution in SAP:

Code quality sweep

The code Kiro generates does not go out into the world on its own. From the IDE, the agent can run quality validations right away: an ATC (ABAP Test Cockpit) review that delivers results by severity (Error, Warning, Info), a syntax check to verify compilation, and the execution of existing ABAP unit tests or the generation of new ones. All of this happens without opening Eclipse or SAP GUI, because the full generation-and-validation cycle takes place inside Kiro, without switching tools.
The next level is to use Steering as a team standard, as we saw earlier. Kiro lets you define a Steering file that encodes the customer's quality standard: naming conventions, comment structure, modularization rules, and the use of classes over legacy programs. That Steering accompanies every interaction the agent has with the team, not as a later review, but as an active guide during development. This way, the team's behavior becomes more consistent.

ECC → S/4HANA migration analysis

The ABAP Accelerator includes the get_migration_analysis tool, which analyzes ABAP code and identifies incompatibilities with S/4HANA, such as obsolete tables, deprecated functions, and patterns that violate clean core. The scope of the analysis is defined in the ABAP Accelerator repository documentation, which makes it auditable and extensible. The agent proposes the conversion and validates it with ATC within the same flow.

Extensibility: building your own tools with Kiro

The ABAP Accelerator does not cover every scenario, and it does not have to. The MCP in local mode is extensible, and Kiro can build that extension for you.
Let's look at a concrete example: tracing logic in SAP BW transformations. The ABAP Accelerator does not include native tools for BW, but that is an opportunity rather than a limitation. You ask Kiro to build a new tool that extracts and traces the complete logic of a transformation, with its start routines, end routines, field-mapping rules, and dependencies between objects. Kiro generates the tool, adds it to your local MCP, and from then on the agent uses it like any other.
This applies to the use cases your team needs and that the base MCP does not cover yet, as long as they can be solved with the available ADT APIs. The barrier is usually not technical, but stating the requirement.

Technical requirements

The following table summarizes the requirements of each MCP server for technical SAP teams:
ComponentRequirement
ABAP Accelerator
Minimum SAP versionSAP NetWeaver 7.31 SP4+ with ADT enabled
Recommended versionNW 7.50+ / S/4HANA (full support: ATC, unit tests, RAP)
Required SAP rolesSAP_BC_DWB_ABAPDEVELOPER + SAP_BC_TRANSPORT_OPERATOR
ICF services/sap/bc/adt/ node activated in SICF
EnvironmentsNon-production only: DEV, SBX, QAS, TST
DeploymentLocal Python, Docker, or Amazon ECS with AWS Fargate
ConnectivityHTTP/HTTPS from the MCP server to SAP
Setup timeApproximately 15 to 30 minutes locally (estimate, depending on the environment)
SDK ABAP Knowledge
SAP versionNW 7.4+ (to use the underlying SDK in the system)
InstallationOnly add a URL to mcp.json
AuthenticationNone, public endpoint
CostFree
The following screenshot shows the required SAP roles as seen in the SU01 transaction:
About the roles, it helps to understand what each one enables. The SAP_BC_DWB_ABAPDEVELOPER role gives access to the source code through ADT. The SAP_BC_TRANSPORT_OPERATOR role allows you to create objects, assign them, and release transport requests in the development system. The MCP covers up to the release of TRs; the transport cycle between systems (from DEV to QAS to PRD) stays out of scope, as is appropriate for a tool focused on non-production environments.
Rule of thumb: if your team already uses Eclipse with ADT to develop, the ABAP Accelerator can connect without changes. If they only use SAP GUI (SE80), Basis must activate the ADT ICF services and assign the corresponding roles.

How to get started today

Step 1: install Kiro

Download Kiro from kiro.dev . The installation is standard and works on Windows, macOS, and Linux.

Step 2: configure SDK ABAP Knowledge

This MCP is the fastest to enable. Open ~/.kiro/settings/mcp.json and add the following configuration:
1
2
3
4
5
6
7
8
9
{
"mcpServers": {
"abap-sdk-knowledge": {
"url": "https://sdk-for-sap-abap-knowledge-mcp.global.api.aws/mcp",
"disabled": false,
"autoApprove": ["*"]
}
}
}
It works immediately, with no authentication or additional installation. To verify it end-to-end, open Kiro and ask it in natural language to generate ABAP code that uploads a file to Amazon S3 using the AWS SDK for SAP ABAP. The agent queries the documentation through the MCP and returns syntactically correct code, ready to review.

Step 3: configure ABAP Accelerator (if you have access to SAP DEV)

This MCP requires a few more steps, because it connects to your SAP system. The end-to-end procedure is as follows:
  1. Clone the guidance-for-deploying-sap-abap-accelerator-for-amazon-q-developer repository.
  2. Configure the credentials securely (SAP host, client, and user).
  3. Start the server with .venv/bin/python src/aws_abap_accelerator/main.py.
  4. Add the local ABAP Accelerator entry to Kiro's mcp.json:
1
2
3
4
5
6
7
8
9
{
"mcpServers": {
"abap-accelerator": {
"url": "http://localhost:8000/mcp",
"disabled": false,
"autoApprove": ["*"]
}
}
}
  1. Verify the full flow: open Kiro, ask it to document a known Z program, and confirm that the agent reads the system's source code and returns the documentation. With that, the connection between Kiro, the MCP, and SAP is validated.
For credentials there are three alternatives, summarized in the following table:
MethodHow it worksWhen to use it
.env fileVariables in a file the MCP reads at startup. Add .env to .gitignore.Recommended for local, direct and secure
OS environment variablesexport SAP_HOST=... in the shell sessionMore secure (not stored on disk) but less convenient
Docker --env-filedocker run --env-file .env abap-acceleratorIf you use the container
⚠️ Do not leave SAP credentials in the mcp.json file. That file is often in the project repository. Always use .env or environment variables.
💡 Tip: you can ask Kiro to configure this for you: "Create a .env file for the ABAP Accelerator with the variables SAP_HOST, SAP_CLIENT, SAP_USER, and SAP_PASSWORD, and add it to .gitignore". Kiro creates the structure, the .gitignore, and validates the connection.
As a security recommendation, create a dedicated SAP technical user for the MCP, with only the two required roles and pointing exclusively to DEV or SBX.

Full documentation

The complete reference is at docs.aws.amazon.com/mcp-sap .

Clean up resources

When you finish testing the ABAP Accelerator, it is good practice to revert the configuration so you do not leave the MCP server or the credentials active. Follow these steps to clean up the environment.
  1. Stop the MCP server. If you run it with Python locally, stop the main.py process (with Ctrl+C in the terminal where it runs). If you use Docker, stop and remove the container with docker stop abap-accelerator and then docker rm abap-accelerator. If you deployed it on Amazon ECS with AWS Fargate, scale the service down to zero tasks or delete the stack that created it.
  2. Remove the configuration from mcp.json. Open ~/.kiro/settings/mcp.json and delete the abap-accelerator entry for the ABAP Accelerator (the block that points to your local server on port 8000). Do the same with the abap-sdk-knowledge entry if you no longer need it. Kiro reloads the configuration without restarting.
  3. Delete the local credentials. Remove the .env file with the SAP variables and, if you exported environment variables in the shell, close it or use unset for each one.
  4. Review the SAP technical user. If you created a dedicated user for the MCP, lock or delete it in SU01 when you no longer use it, along with the roles assigned for this test.
After these steps, Kiro goes back to operating without access to the SAP system and no credentials remain on disk.

Considerations

Before implementing, keep three points in mind. The ABAP Accelerator is designed exclusively for non-production environments (DEV, SBX, QAS, TST) and must not be used in production systems. Regarding the SAP API policy of April 2026, SAP published a policy that restricts the use of APIs for autonomous AI agents outside of "approved architectures"; the ABAP Accelerator uses ADT, which are documented SAP APIs, and its use in development environments reduces the risk, but it is advisable to consult with SAP and your organization's legal team before implementing integrations in non-DEV environments. Finally, Kiro does not replace the SAP developer, but gives them more context and speed, and control remains with the technical team.

Architecture: Kiro + ABAP Accelerator MCP

The following diagram shows how Kiro connects to the SAP system through the ABAP Accelerator MCP:
Architecture: Kiro + MCP for SAP
Architecture: Kiro + MCP for SAP
The workflow goes through four steps. First, the developer works in Kiro and writes a prompt, for example "document this Z program." Second, Kiro invokes the ABAP Accelerator MCP through local HTTP (or remote on Amazon ECS with AWS Fargate). Third, the ABAP Accelerator connects to the SAP system through the ADT protocol (REST over HTTPS) and reads or writes ABAP objects. Fourth, in parallel, the SDK ABAP Knowledge MCP provides the knowledge to generate ABAP code that integrates AWS services such as Amazon S3, Amazon Bedrock, and Amazon DynamoDB.
The following table compares the ABAP Accelerator deployment options:
OptionWhere it runsSAP authIdeal for
Local PythonDeveloper's laptop.env fileQuick tests
Local DockerLaptop (container)--env-fileMulti-system, isolated
Amazon ECS with AWS FargateAWS (managed container)Principal Propagation + OAuth 2.0Full team
Full architecture documentation: docs.aws.amazon.com/mcp-sap 

About the authors

Rosmar Torres is a Solutions Architect at AWS Chile, covering enterprise accounts. With 9 years of experience in SAP BW/HANA and SAP Analytics, she combines deep SAP expertise with a strong focus on Generative AI to help customers accelerate their cloud adoption and modernization journeys. She created this adaptation as a personal contribution, drawing from her hands-on experience accompanying multiple customers through architecture engagements in Chile.
Francisco Fagas is a Senior Specialist Solutions Architect for Generative AI at AWS, based in San Juan, Puerto Rico, covering LATAM NOLA enterprise accounts. With more than 20 years of experience in IT, he combines deep technical expertise across cloud architecture, application development, and AI/ML to help enterprise customers adopt Generative AI and accelerate innovation through agentic AI, large language models, and modern development practices.

About the reviewers

César Andrés Páez Román is a Senior Migrations and Modernization Solutions Architect at AWS Chile, covering LATAM enterprise accounts. With 15 years of experience in SAP infrastructure (S/4HANA, ERP, Business Suite on HANA, Netweaver) and cloud migrations, he combines deep SAP technical expertise with a strong focus on helping customers accelerate their cloud adoption and modernization journeys at executive level. He created this adaptation as a personal contribution, drawing from his hands-on experience leading migration and modernization engagements across multiple customers in Chile and LATAM.
Felipe Chirinos is a Solutions Architecture Manager for AWS, based in Santiago, Chile. He has over 15 years of experience in technology solutions across the region and is certified as an AWS Solutions Architect Professional.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article