Based on the provided server schema, this server exposes only the sap_systems tool: it reports the state of the SAP system configuration.
Lists configured SAP systems and their settings (role, write permissions, data class, modules).
Optionally checks connectivity and which tools work on each system.
The schema does not expose the 45 tools described in the README; only sap_systems is available.
Provides secure, verifiable access to SAP ABAP systems (ECC 6.0 / NW 7.50 and S/4HANA) via ADT over HTTPS. Exposes 45 tools across 9 groups for reviewing code and transport orders (diffs, contents, co-change analysis, inactive objects, edit preflight), running ATC checks and applying SAP-proposed quick fixes, checking API release state and syntax, running ABAP Unit tests, exploring the repository (search, source reading, where-used, versions, package contents, DDIC types, transactions, text elements), read-only ABAP SQL queries, incident diagnosis (dumps, job and application logs), looking up SAP documentation, and authorized writes into the correct transport order on development systems only. Also integrates with a DoZimple Transport Risk ICF service to assess whether a transport set is ready for QA or production.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@abap-adt-doZimple Run ATC on ZDEMO_REPORTE and explain the P1 findings"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English · Español
AI that works on your SAP system with the rules of a senior consultant.
An MCP server by DoZimple that gives AI agents — Claude Code, Kiro or any MCP client — secure, verifiable access to SAP ABAP systems: review code and transport requests, run ATC and ABAP Unit, diagnose incidents, query the official documentation and, where authorized, save changes in the right transport after a human confirms them.
45 tools · 9 functional groups · 3 guided flows · ECC 6.0 (NW 7.50) and S/4HANA
Features · Full tool reference · Security · Threat model · DoZimple Transport Risk · Credits · Contact
“What does transport DEVK900123 really change, and which objects usually travel with it but are missing?”
“Run ATC on ZDEMO_REPORT, explain the P1 findings with their SAP note and propose the fix SAP offers.”
“Can I use
CONDon this 7.50 system? If not, rewrite the method with compatible syntax and validate it against SAP.”“Last night's billing job failed: dumps, job log and application log, and tell me the probable cause.”
“Is this release of four transports ready for production? Explain it in business terms for the PMO.”
The agent picks the tools, chains them and answers with evidence. Every answer states which system it comes from, and a failure is never presented as an empty result or as success.
Related MCP server: ABAP Transport Analyzer MCP Server
Usual approach | abap-adt-doZimple | |
Systems | One per instance, no roles | Every system in the landscape, with a policy per role: DEV / QAS / PRD |
Writes | Saves wherever SAP decides, or cannot write at all | Development only, explicit transport, preview and human confirmation; stops on another transport's CTS lock |
Verification | abaplint or nothing | SAP's real syntax check, also on code not saved yet |
Parameters | A misspelled parameter is silently ignored and the call runs anyway | Unknown parameters are rejected with the list of accepted ones: a misspelled |
Results on failure | Empty lists or misleading “OK” | Typed error saying what could not be checked and why |
Releases | Hard-coded endpoints | Capabilities read from each system's ADT discovery |
IDE | Often requires the IDE open | Standalone server, no IDE |
Third parties | Dependencies mixed with credentials | Components isolated in their own process and filtered |
Data | Whatever the SAP user can read goes to the model | Security and HR tables blocked (also through views and CDS); personal data masked on production-data systems |
Group | What for | Tools |
Know what a transport really changes and what it may break, before releasing it. | 5 | |
Find, understand and fix findings with SAP's real syntax check and quick fixes. | 6 | |
Read and understand any ABAP object and its relations, on ECC and S/4HANA. | 11 | |
Query tables with ABAP SQL, read-only, with sensitive and personal data protected. | 2 | |
One conversation for what used to take ST22, SM37, SLG1 and /IWFND/ERROR_LOG. | 4 | |
Answer from official documentation and check which syntax exists in each release. | 7 | |
Save changes only in development, in the right transport, previewed and confirmed by a human. | 5 | |
Decide whether a whole release can go to QA or production, with the why in business terms. | 7 | |
See what works on each system and decide the next tool with data. | 4 |
flowchart LR
subgraph Client["MCP client (Claude Code, Kiro…)"]
A[AI agent]
end
subgraph Srv["abap-adt-doZimple (stdio, no ports)"]
R["Registry and policy<br/>system · role · capability · module<br/>confirmation · audit"]
T["45 tools + 3 flows"]
K[("OS keychain")]
D["Docs component<br/>(isolated process)"]
end
subgraph SAP["SAP systems"]
DEV["DEV — read and, if authorized, write"]
QAS["QAS / PRD — read only"]
TR["DoZimple Transport Risk<br/>(SAP component)"]
end
A <-->|MCP| R --> T
T -->|ADT over HTTPS| DEV
T -->|ADT over HTTPS| QAS
T -->|ICF service| TR
T --> D
R -.credentials.-> K
D -.filtered queries.-> W[(SAP documentation)]Summary per group; each tool's details — parameters, types, defaults, requirements and credits — are in the full reference (in Spanish).
Know what a transport really changes and what it may break, before releasing it.
Tool | What it does | Access |
What a transport changed (code diff). Code review of a transport: for each source object (programs, includes, classes, interfaces, function modules, CDS) compares the version recorded with that transport against the previous one and shows a unified diff. | read | |
Transport contents. Header, tasks (owner and status) and objects of a transport request, read from E070/E07T/E071. | read | |
What usually travels with this object? Looks at the transports that touched an object and counts which other objects travelled with it, most frequent first. | read | |
Inactive objects. Objects saved but not activated by the connection user, with their transport. | read | |
Before editing: which transport will it land in? Tells, BEFORE changing an object, which transport the change will end up in and why: CTS lock by another transport, local object ($TMP), repair (different original system), or free with your open transports. | read |
Find, understand and fix findings with SAP's real syntax check and quick fixes.
Tool | What it does | Access |
Run ATC. Runs the ABAP Test Cockpit on an object or a transport and lists numbered findings (priority, line, check, message) with SAP's P1/P2/P3 totals. | read | |
SAP-proposed fixes. The fixes SAP offers (the same as Ctrl+1 in Eclipse) for an ATC finding or a line: create text symbol, extract constant, etc. | read | |
Is this API released? What is its successor? Release state of an SAP object (class, function module/BAPI, table, CDS…) by contract C0–C4 and its released successor, read from the system itself. | read | |
SAP notes in the system (SNOTE). Whether a note is downloaded in this system, its implementation and processing status, version, component and title, per note or filtered by status/component; no SAP portal or S-user needed. | read | |
SAP syntax check. SAP's real syntax check (not abaplint), also on code not saved yet. | read | |
Run ABAP Unit. Runs the ABAP Unit tests of a class or program (harmless and short only) and returns the result per method, with each failure in detail. | executes (DEV) |
Read and understand any ABAP object and its relations, on ECC and S/4HANA.
Tool | What it does | Access |
Search ABAP objects. Searches repository objects by name (supports * wildcards). | read | |
Read ABAP source. Reads the source of any object: program, include, class (and its includes), interface, function module (without knowing its group), CDS, table/structure, etc. | read | |
Where used. Where-used list of an object: who references it, with package and owner. | read | |
Search text in source code. Searches a text or regex in the source of a package (with subpackages), a transport or a list of objects, and returns object, include, line and the matching line; reaches what where-used misses (dynamic calls, literals, Z code outside the reference index). | read | |
Object versions. Version history of an object (date, author, transport). | read | |
Package contents. Objects of a development package grouped by type, with subpackages (TADIR/TDEVC, any release). | read | |
Data element, domain or table type. Definition of a DDIC type: data element (domain, type, length, texts), domain (type, length, fixed values, value table) or table type (line type, key). | read | |
What a transaction runs. Program, screen and parameters of a transaction (TSTC/TSTCP), with its text. | read | |
Function modules of a group. Lists the function modules of a function group with their text and whether they are RFC or update modules; given a module, finds its group and siblings. Works with /XXX/ namespaces. | read | |
Text symbols and selection texts. Reads the text symbols (TEXT-001…), selection texts or headings of a program, class or function group. | read | |
Enhancements and BAdIs. Implementations of a BAdI (new and classic, active or not), source code enhancements implemented inside a program, class or function group (flagging those that overwrite standard code), or all enhancement implementations of a namespace by type. | read |
Query tables with ABAP SQL, read-only, with sensitive and personal data protected.
Tool | What it does | Access |
ABAP SQL query. Runs an ABAP SQL SELECT (WHERE, JOIN, ORDER BY, subqueries) through ADT data preview, with personal columns masked and row caps on production-data systems. | read | |
Table contents. Rows of a table, view or CDS, with optional columns and filter. | read |
One conversation for what used to take ST22, SM37, SLG1 and /IWFND/ERROR_LOG.
Tool | What it does | Access |
Dumps (ST22). Lists runtime dumps: date, error, program, user and short text. | read | |
Background jobs (SM37). Background jobs by name (supports *), user, status and date, with their steps (program and variant). | read | |
Application log (SLG1) headers. Application log headers (BALHDR) by object/subobject, external number, user and date, with error and warning counts. | read | |
SAP Gateway errors (/IWFND/ERROR_LOG). Lists SAP Gateway (OData) errors: service, error, user, date. | read |
Answer from official documentation and check which syntax exists in each release.
Tool | What it does | Access |
Since which release does this syntax exist? Availability of each ABAP language feature per release (7.40 … 7.58, 2025). | local | |
Search ABAP documentation. Searches the official ABAP keyword documentation (standard and cloud), Clean ABAP, the DSAG guide, ABAP cheat sheets and RAP samples, locally. | local | |
Read a documentation page. Returns the full content of a document by the id docs_search gives. | local | |
Released objects catalog (Clean Core). Searches SAP's public catalog (abap-atc-cr-cv-s4hc, local) for released/deprecated objects by name or topic, with Clean Core level (A released … D all) and successors. | local | |
Clean Core state of an SAP object. Release state, Clean Core level and successor of an SAP object according to the public catalog (local). | local | |
abaplint on a snippet. Runs abaplint locally (code never leaves the machine) on an ABAP snippet or source. | local | |
Search SAP Community. Searches SAP Community (blogs and questions) by error message, class or concept. | local |
Save changes only in development, in the right transport, previewed and confirmed by a human.
Tool | What it does | Access |
Save source to SAP. Replaces the FULL source of an existing object (or class include) in the given transport, after a preview with syntax check and diff and a human confirmation. | writes (authorized DEV) | |
Revert to an earlier version. Writes back an earlier version of an object (the last active one, the one before it, or a numbered one from object_versions) through the same preview, fingerprint, lock and transport as write_source; never reverts on its own. | writes (authorized DEV) | |
Activate object. Activates an object and returns SAP's messages as they are (errors with line, warnings, objects left inactive). | writes (authorized DEV) | |
Create or change text symbols. Adds or changes text symbols (or selection texts) of a program/class/group, merging with the existing ones: nothing not mentioned is deleted. | writes (authorized DEV) | |
Create transport request. Creates a workbench request for an object's package BEFORE the first edit, so the change lands in the ticket's transport and not in a reused task. | writes (authorized DEV) |
Decide whether a whole release can go to QA or production, with the why in business terms.
Tool | What it does | Access |
Transport risk. Tells whether a transport (or a release of several, comma-separated) is safe to move to QA or production: unreleased tasks, import status, dependencies that don't travel, positional access, CTS locks, import queue. | read | |
Import health. Health of the imports into a target (QA or production): answers “how are the releases to production going?”. | read | |
Objects that fail most on import. Ranking of objects by import failure history in a target. | read | |
Change audit evidence. Evidence for a change management audit on a target: what went in, with which ticket, initiative and origin. | read | |
Transport history of an object. Which transports touched an object, when, and which already reached the target. | read | |
Source on the target. The source of an object AS IT IS in QA or production, read through TMS (like “Retrieve remote versions”). | read | |
Transport code against the target. Compares the code of a transport's objects with the target: objects missing there (R3.4) and version drift — signatures, fields or parameters that differ and don't travel in the transport (R3.5). | read |
See what works on each system and decide the next tool with data.
Tool | What it does | Access |
SAP systems and available tools. Lists the configured systems (role, writes, data class, modules) and, optionally, checks connectivity and which tools work on each. | local | |
Record a missing tool. Records a need no tool covers (e.g. something you had to do manually in a transaction), to decide what to build next. | local | |
Close a recorded gap. Marks a gap recorded with report_gap as resolved, with a note (a tool now covers it, or the note turned out to be wrong); nothing is deleted. | local | |
Tool usage and gaps. Summary of the local log: calls per tool, failure rate and type, systems, and the gaps recorded with report_gap. | local |
They show up as commands in the MCP client (in Claude Code: /mcp__abap-adt-doZimple__<name>) and chain the tools
with the working rules of a senior consultant.
Flow | What it does | Chain |
| Full review of a transport: code, missing companions, locks and, with the risk module, its analysis. | transport_contents → transport_diff → inactive_objects → co_change + edit_preflight → analyze_transport_risk (if module) → three-layer report: business, consultant, Basis |
| ATC → documentation and SAP note → released successor → fix → syntax → save in the transport. | edit_preflight → run_atc (BEFORE) → explain + api_release_state + where_used/object_versions → CHANGE/INVESTIGATE/KEEP classification → atc_quickfix → syntax_check → write_source in the transport (with human OK) → run_atc (AFTER) and P1 reduction |
| Dumps, jobs, application log and Gateway errors around an incident. | dumps → jobs → application_log → gateway_errors → transaction_info / get_source / object_versions / transport_contents → probable cause with evidence and what could not be checked |
The most valuable module for operations: before releasing, it tells whether a transport or a whole release can go to QA or production, and why not, in three layers — a business verdict for the PMO, what to review for the consultant, and release actions for Basis.
Whole releases, not single transports: what travels in one transport covers the others; it computes the import sequence and detects mutual dependencies and collisions between transports.
What breaks silently: positional access to structures that change, code and dictionary dependencies that don't travel and don't exist on the target, version drift.
The real state of the landscape: target import queue, CTS locks, transports of copies that drag other people's changes, import health and the objects that fail most.
Evidence for change management audits.
It works on any ABAP stack with CTS (ECC and S/4HANA) and is read-only on every system. It requires a proprietary DoZimple SAP component (ICF service in development and read-only RFCs on the targets), which is not distributed in this repository.
Want it in your landscape? → dozimple.cl
Designed to pass a Security and Basis review without exceptions. Details: SECURITY.md and the threat model (STRIDE and OWASP Top 10 for LLM applications).
No network surface: stdio only; no ports are opened.
Credentials in the OS keychain (macOS Keychain or Linux Secret Service), never in files, logs or responses.
Policy per role: QA and production are never written; development only with explicit authorization.
Strict parameters: an unknown or misspelled parameter is an error listing the accepted ones, never silently ignored.
No write without human confirmation: a preview with SAP's syntax check and the real diff, confirmed through MCP elicitation or a single-use token bound to those exact arguments.
Hash-chained audit log of every write and execution, fail-closed (no log, no write), verifiable with
npm run audit:verify.
SAP credential material and HR data blocked in SQL queries, also through views and CDS, even if the SAP user is authorized. Validated against a real S/4HANA 2023 system, where standard views and CDS read USR02 without naming it.
Personal data masked and row caps on systems with production data.
No customer data to the internet: online documentation search is off by default and, when enabled, every query with objects, transports, systems, users or customer names is blocked.
Third parties isolated in their own process with a minimal environment.
Controlled supply chain: 4 production dependencies pinned to exact versions, no install scripts, verified registry signatures, CycloneDX SBOM, audit and secret scanning on every commit and in CI.
SAP | ECC 6.0 / NetWeaver 7.50 and later, and S/4HANA on-premise or private cloud, through ADT ( |
MCP clients | Claude Code, Kiro and any MCP client over stdio |
Platform | Node.js 22+. Credentials in the macOS Keychain, the Linux Secret Service or environment variables |
Pinned to an exact version, without install scripts, like the project's own dependencies:
npm install -g --ignore-scripts @dozimple/abap-adt@1.2.0
PKG="$(npm root -g)/@dozimple/abap-adt"
mkdir -p ~/.config/abap-adt-dozimple && chmod 700 ~/.config/abap-adt-dozimple
cp "$PKG/config/systems.example.json" ~/.config/abap-adt-dozimple/systems.json # systems, roles and permissions
chmod 600 ~/.config/abap-adt-dozimple/systems.json
sh "$PKG/scripts/set-password.sh" MY_DEV # prompts; stored in the keychain
node "$PKG/dist/scripts/smoke.js" MY_DEV # read-only validationMCP client registration:
{ "mcpServers": { "abap-adt-doZimple": { "command": "abap-adt-dozimple" } } }Every release is published from CI with npm provenance:
npm view @dozimple/abap-adt@1.2.0 dist.attestations shows the attestation, and the GitHub release carries the
tarball, its Sigstore bundle (.sigstore.json), the same bundle as in-toto provenance (.intoto.jsonl) and the
SBOM. To check it: gh attestation verify dozimple-abap-adt-1.2.0.tgz --repo <owner>/abap-adt-dozimple.
npm ci && npm run build
mkdir -p ~/.config/abap-adt-dozimple
cp config/systems.example.json ~/.config/abap-adt-dozimple/systems.json # systems, roles and permissions (chmod 600)
scripts/set-password.sh MY_DEV # prompts for the password; stored in the keychain
npm run smoke -- MY_DEV # read-only validationMCP client registration:
{ "mcpServers": { "abap-adt-doZimple": { "command": "node", "args": ["/path/to/abap-adt-doZimple/dist/index.js"] } } }SAP documentation group (optional): install mcp-sap-docs
(Apache-2.0, abap variant) in a separate folder and declare how to start it in sidecars.docs of systems.json
(see config/systems.example.json). It runs as an isolated process; online search stays off unless allowOnline.
See CONTRIBUTING.md. To contribute or extend: git config core.hooksPath .githooks (secret and customer-data scanner before every commit)
and the nueva-tool guide — adding a tool means adding one file. Code comments
and tool descriptions are in Spanish; contributions in English are welcome.
abap-adt-doZimple is built on other people's work, and says so: each tool lists its credits in the reference. Dependency: its code is used. Data: third-party content that is queried. Idea: a design studied and reimplemented without copying code. Algorithm: a published method.
Project | Author / holder | License | Type | Used in |
Marcello Urbani | MIT | dependency | all (core), | |
Model Context Protocol | MIT | dependency | all (core) | |
Marian Zeis (marianfoo) | Apache-2.0 | dependency |
| |
Lars Hvam and contributors | MIT | dependency |
| |
Colin McDonnell and contributors | MIT | dependency | all (core) | |
SAP SE | © SAP SE | data |
| |
SAP (SAP-samples) | Apache-2.0 | data |
| |
SAP | per repository | data |
| |
DSAG e.V. | per repository | data |
| |
Software-Heroes | © Software-Heroes | data |
| |
Released objects / Cloudification Repository (abap-atc-cr-cv-s4hc) | SAP | Apache-2.0 | data |
|
SAP SE and community authors | SAP terms | data |
| |
Marcello Urbani | MIT | idea |
| |
mario-andreschak | MIT | idea |
| |
arc-mcp (Marian Zeis and contributors) | MIT | idea |
| |
oisee and contributors | MIT | idea |
| |
AWS Solutions Library Samples | MIT-0 | idea | all (core), | |
Eugene W. Myers | published algorithm | algorithm |
|
Full dependency licenses: THIRD_PARTY_NOTICES.md. If you are the author of one of these projects and want to adjust how you are credited, reach us at dozimple.cl.
DoZimple — technology that connects operations, data and innovation. SAP consulting and development (ABAP, CDS, OData, RAP, Fiori), integration and SAP BTP, software and portals connected to the ERP, and applied artificial intelligence over controlled sources, with reproducible answers and human review.
This MCP server is an example of how we work: useful AI, with control, traceability and security by design. Let's talk → dozimple.cl
Apache-2.0 — © 2026 DoZimple. See also NOTICE. The DoZimple Transport Risk SAP component is proprietary and not part of this repository. SAP, ABAP and S/4HANA are trademarks of SAP SE; this project is not affiliated with SAP SE.
Estado de la configuración de sistemas SAP.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it says nothing about whether the call is read-only, what permissions are needed, or how expensive/slow the call may be. For a monitoring-style tool the read-only nature is strongly implied by 'Estado', but nothing explicit is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and the resource front-loaded. It is efficient, though the terseness borders on under-specification rather than true conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is the only place that could explain what the returned status contains (fields, per-system grouping, pass/fail semantics), and it does not. For a zero-parameter tool the call itself is trivial, but the result shape is entirely opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to document. The baseline of 4 applies since the schema imposes no burden the description must compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (SAP systems) and the aspect being reported (configuration status), which is more than a tautology. However, it has no explicit verb, so it is ambiguous whether the tool reads, validates, or monitors configuration, and there are no siblings to differentiate against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this tool, what prerequisites exist, or how it relates to any other capability. The single sentence is purely a label and leaves all usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0sap_systemsScored across 1 tool
With only a single tool there is no possibility of overlap or misselection, so ambiguity between tools is zero. However, the tool's own purpose ('Estado de la configuración de sistemas SAP') is vague and does not clearly state what action it performs or returns.
The single name 'sap_systems' uses a clean snake_case convention, but it is a bare noun phrase with no verb, so no predictable verb_noun pattern exists to evaluate. With one tool, consistency is neither violated nor demonstrated.
A single tool is far too thin for a server named 'abap-adt-doZimple', which implies ABAP ADT development operations such as reading, editing, activating, and transporting objects. One config-status tool cannot cover that scope.
The surface is severely incomplete: an ABAP/ADT server would need tools for object retrieval, source editing, activation, transports, and system listing, yet only one status-report tool is exposed. Agents would hit immediate dead ends for any real development workflow.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Give AI agents 30,000+ safe, token-optimized actions across Workday, SAP, Oracle + hundreds more.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
