Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
ARC-1 — SAP ADT MCP Server
ARC-1 (pronounced _arc one_ [ɑːrk wʌn]) — Enterprise-ready MCP server for SAP ABAP systems. Secure by default, deployable to BTP or on-premise, and hardened with large unit/integration/E2E test coverage.
ARC-1 connects AI assistants (Claude, GitHub Copilot, Copilot Studio, and any MCP client) to SAP systems via the ADT REST API. It ships as an npm package and Docker image.
[Full Documentation](https://docs.arc-1-mcp.com/) | [Quickstart](https://docs.arc-1-mcp.com/quickstart/) | [Security Review](https://docs.arc-1-mcp.com/security/) | [Tool Reference](https://docs.arc-1-mcp.com/tools/) | [ARC-1 Updates](https://docs.arc-1-mcp.com/newsletter/) | [Blog Series](https://blog.zeis.de/tags/ai-abap-development-series/)
📬 Stay current with ARC-1 — get major releases, upgrade and security notes, practical guides, and occasional questions where your feedback can shape what comes next. [Join ARC-1 Updates →](https://docs.arc-1-mcp.com/newsletter/)
📖 New: AI ABAP Development blog series — long-form posts on AI for ABAP, ARC-1 design, and real-world BTP / Copilot Studio / Joule walkthroughs. [Read the series →](https://blog.zeis.de/tags/ai-abap-development-series/)
Why ARC-1?
Built for organizations that need AI-assisted SAP development with guardrails. Inspired by the pioneering work of abap-adt-api, mcp-abap-adt, and vibing-steampunk — ARC-1 adds what's needed to run in production:
Security & Admin Controls
- Safe by default — read-only, no free SQL, no table preview, no transport writes, no Git writes. Enable each capability with explicit
SAP_ALLOW_*flags - Action deny list — block specific tool actions with
SAP_DENY_ACTIONS(for exampleSAPWrite.delete), without exposing low-level operation codes to admins - Package restrictions — limit AI write operations (create, update, delete) to specific packages with wildcards (
--allowed-packages "Z*,$TMP"). Read operations are not restricted by package — use SAP's native authorization for read-level access control - Data access control (off by default) — table previews, saved SAPscript texts and SLG1 messages require
SAP_ALLOW_DATA_PREVIEW=true; freestyle SQL separately requiresSAP_ALLOW_FREE_SQL=true. Review enabled uses against the SAP API Policy, your SAP agreement, and internal data-governance rules. - Experimental data-source emergency brake — approved data/SQL deployments can set
SAP_BLOCKED_DATA_SOURCES=USR02,PA0002. ARC-1 then parses each SQL request and resolves active CDS plus replacement-object lineage before execution, denying direct or transitive exact-name matches and failing closed when lineage is unsupported or cannot be proven. The empty default adds no metadata calls. This denylist is defense in depth, not a production allowlist or replacement for SAP authorization/CDS DCL; see Authorization & Roles. - Transport safety — transport reads are available for review, while transport mutations require both
--allow-writesand--allow-transport-writes. Update/delete operations auto-use the lock correction number when no explicit transport is provided - Git workflow safety — Git operations are disabled by default. Enable explicitly with
--allow-git-writes/SAP_ALLOW_GIT_WRITES=true - API-key profiles — multi-key HTTP deployments can assign
viewer,viewer-data,viewer-sql,developer,developer-data,developer-sql, oradminper key - Writes restricted to `$TMP` when enabled — only local/throwaway objects; writing to transportable packages requires explicit
--allowed-packages - HTTP security headers (helmet) on by default — HSTS, CSP, X-Frame-Options, CORP, X-Content-Type-Options. COOP is deliberately not set so popup-based OAuth flows (Copilot Studio) keep working. No flag to disable.
- Opt-in CORS for browser MCP clients —
ARC1_ALLOWED_ORIGINS(comma-separated, exact match). Off by default; native MCP clients don't need it - Layered rate limiting — three layers out of the box: per-IP OAuth and shared MCP HTTP edge limits (Layer 1; MCP inherits the historical derived cap unless
ARC1_MCP_HTTP_RATE_LIMIToverrides it), per-user MCP quota (Layer 2, off by default — multi-user deployments opt in viaARC1_RATE_LIMIT=60), and a server-wide SAP-bound semaphore (Layer 3, default 10, on). HonorsRetry-Afteron 429/503 from SAP / BTP gateways. See the Rate Limiting Guide - Dependency and release evidence — Dependabot, npm audit and Dependency Review checks, CodeQL, Trivy container scanning, npm provenance, and a best-effort CycloneDX SBOM for the release's production npm lockfile graph. Section 13 of the security guide lists what each artifact covers, how to verify it, and the gaps. Vulnerability response targets are best-effort and non-contractual.
Authentication
- API key — simple Bearer token for internal deployments
- OIDC / JWT — Entra ID, Keycloak, or any OpenID Connect provider
- OAuth 2.0 — local browser-based login for BTP ABAP Environment service-key development
- XSUAA — SAP BTP native auth with automatic token proxy for MCP clients
- Per-user SAP identity — BTP Destination Service forwards the MCP user to SAP: Cloud Connector principal propagation for on-premise SAP, or
OAuth2UserTokenExchangefor BTP ABAP Environment
BTP Cloud Foundry Deployment
Deploy ARC-1 as a Cloud Foundry app on SAP BTP with full platform integration:
- Destination Service — connect to SAP systems via managed destinations
- Experimental multi-target mode — the default-off BTP mode discovers
destinations marked arc1.enabled=true and exposes pinned SID/client plus read-only aggregate endpoints; scoped pinned PP writes require separate destination/IAM opt-ins (setup, administration)
- Optional target filtering — for shared multi-system gateways where teams need different target
lists. Assign systems/clients through XSUAA roles; IAS changes are optional. This filters IAM-assigned targets, not automatically discovered SAP accounts.
- Cloud Connector — reach on-premise systems through the connectivity proxy
- Per-user destinations — user identity forwarded end-to-end via X.509 certificates for on-premise SAP, or exchanged for an ABAP bearer token for BTP ABAP Environment
- XSUAA OAuth proxy — MCP clients authenticate via standard OAuth, ARC-1 handles the BTP token exchange
- Audit logging — structured events to stderr, file, or BTP Audit Log Service
Token Efficiency
- 12 intent-based tools instead of 200+ individual tools — keeps tool selection simple, with the schema payload guarded by CI budgets and a hyperfocused 1-tool mode for tight context windows
- Method-level read/edit — read or update a single class method, not the whole source (up to 20x fewer tokens)
- Focused source and dependency context — use targeted
SAPReadfor exact implementation behavior. For business purpose, reviews or test design, start withSAPContext(action="deps", type=..., name=...)for available Knowledge Transfer Documents (SKTD/KTD) and dependency contracts, then compare requirements with source. Without documented requirements, intent is unverified.
Built-in Object Caching
- Server-validated source caching — every SAP object read is cached in memory (stdio) or SQLite (http-streamable). Repeated reads use
If-None-Match/ETag conditional GET, so unchanged objects return from cache after SAP confirms304 Not Modified. - Dependency parsing reuse — unchanged, authorized source can reuse parsed dependencies and contracts in memory. Aggregate dependency graphs are not cached; SAP authorization and source validation still apply.
- KTD-aware context — Knowledge Transfer Documents use the source cache and are revalidated when composed into
SAPContext(action="deps"). - Live where-used —
SAPContext(action="usages")and CDS impact analysis query SAP's current repository index with the caller's identity; no startup repository scan is required. - Active/inactive source views —
SAPReadacceptsversion="active" | "inactive" | "auto"and warns when the active source has an unactivated draft. - Write invalidation — when
SAPWriteorSAPActivatemutates an object, both active and inactive source cache entries are dropped; next read revalidates or fetches fresh source.
See [docs/caching.md](docs/caching.md) for full documentation.
Testing
- 3,474 unit tests (
104unit test files, mocked HTTP) - 262-test default integration profile against live SAP systems, with explicit skip reasons when credentials or fixtures are missing
- 141-test default E2E profile that executes real MCP tool calls against a running ARC-1 server and live SAP system
- Manual slow SAP profiles keep broad where-used, RAP full-stack, and recursive CTS release coverage out of the PR path (
test:integration:slow,test:e2e:slow, GitHub SAP Slow Tests workflow) - CRUD lifecycle and BTP smoke lanes included (
test:integration:crud,test:integration:btp:smoke) - CI matrix on Node
22and24; live SAP integration + E2E run on internal PRs and manual dispatch, with SAP jobs gated off for docs/chore PRs and external forks - Reliability telemetry + coverage published as informational CI signals (non-blocking)
Tools Refined for Real-World Usage
The 12 tools are designed from real LLM interaction feedback:
| Tool | What it does |
|---|---|
| SAPRead | Read exact ABAP source, method bodies, grep matches, table data, CDS views, access controls (DCLS), metadata extensions (DDLX), service bindings (SRVB), knowledge-transfer docs (SKTD or friendly alias KTD), message classes (MSAG), revision history (VERSIONS/VERSION_SOURCE), inactive object state, BOR objects, deployed UI5/Fiori apps (BSP, BSP_DEPLOY), and ABAP Platform 2025 server-driven objects (DESD, EVTB, EVTO, DTSC, CSNM, COTA). For "what does this object do?" use SAPContext first, then SAPRead for precise source. Enhancement implementations (ENHO) are readable on-prem and on BTP; authorization fields (AUTH) and feature toggles (FEATURE_TOGGLE) are on-prem only. Structured format for classes returns metadata + decomposed includes as JSON. Optional grep regex returns only matching source lines (+context, method-annotated for classes) for token-efficient search. (Deprecated aliases MESSAGES/FTG2 accepted for one minor.) |
| SAPSearch | Object search + full-text source code search across the system |
| SAPWrite | Create/update/delete ABAP source and DDIC metadata with automatic lock/unlock (PROG, CLAS, INTF, FUNC, FUGR, INCL, DDLS, DCLS, DDLX, BDEF, SRVD, SRVB, SKTD/KTD, TABL, DOMA, DTEL, MSAG; availability adapts for BTP). Class updates can target local includes (definitions, implementations, macros, testclasses); class-section surgery (edit_class_definition, add_method, edit_method_signature, delete_method, change_method_visibility) lets an LLM edit a global class signature without re-sending /source/main; RAP behavior-pool scaffolding can auto-create lhc_* skeletons before injecting signatures/stubs. Batch creation supports terminal activation for interdependent multi-object workflows (e.g., RAP stack or domain+data element in one call) |
| SAPActivate | Activate ABAP objects — single or batch (essential for RAP stacks), with guarded retry for the S/4HANA ED064 batch quirk. Publish/unpublish OData service bindings (SRVB) |
| SAPNavigate | Go-to-definition, find references, code completion |
| SAPQuery | Read saved SAPscript long texts or execute ABAP SQL; each path requires its own opt-in |
| SAPTransport | CTS transport management (list/get/create/release/delete/reassign/release-recursive), transport layer/target lookup, package transport requirement checks, and reverse lookup history (action="history") |
| SAPGit | Git-based ABAP workflows across gCTS and abapGit (list/clone/pull/push/commit/branch/unlink) with backend auto-selection and safety gating (--allow-git-writes) |
| SAPContext | Dependency APIs (action="deps"): optional KTD plus bounded source-derived contracts, not a complete relationship inventory. Also supports live where-used (action="usages"), CDS impact (action="impact"), and TABL includes/appends (action="structure") |
| SAPLint | Local ABAP lint (system/release-aware presets, auto-fix, pre-write validation) + ADT PrettyPrint (server-side formatting) |
| SAPDiagnose | Syntax check, ABAP Unit tests, ATC code quality, CDS test-case suggestions, active/inactive object-state comparison, generic ADT quickfix proposals/application deltas, gateway/system message diagnostics, short dumps, profiler traces, and the on-prem authorization trace (SUAUTHVALTRC, data-preview gated) |
| SAPManage | Feature probing, cache statistics, package lifecycle/change-package operations, and FLP catalog/group/tile helpers |
Tool definitions automatically adapt to the target system (BTP vs on-premise), removing unavailable types and adjusting descriptions so the LLM never attempts unsupported operations.
Feature Detection
ARC-1 probes the SAP system at startup and adapts its behavior:
- Detects HANA, gCTS, abapGit, RAP/CDS, AMDP, UI5, and transport availability
- Auto-detects BTP vs on-premise systems
- Maps SAP_BASIS release to the correct ABAP language version
- Each feature can be forced on/off or left on auto-detect
- In shared-credential mode (technical user), runs a startup auth preflight once and blocks SAP tool calls with a clear error on 401/403 to avoid repeated failed logins and potential user lockout
ADT API Status and Strategy
For a custom MCP server such as ARC-1, SAP's Third-Party MCP Access reference architecture is the primary design and control baseline we recommend. For a shared service, start with BTP Cloud Foundry, XSUAA and strict principal propagation. SAP's API Policy FAQ Q56 allows custom MCP servers under conditions; Q32 confirms that Integration Suite is not mandatory.
[SAP API Policy & Architecture Alignment](docs_page/sap-api-policy-and-architecture.md) explains that path, the controls ARC-1 already supports, and the remaining gaps. FAQ Q33 classifies ADT APIs as internal and limits them to endorsed development channels; ARC-1's direct TypeScript ADT client is not specifically identified as one. Clarify that channel and the intended AI-assisted development use with SAP before adoption, including dev/test. BTP hosting and security controls alone do not establish full policy adherence. Per-user SAP identity applies to PP; shared Basic modes retain a shared SAP identity.
Two ARC-1 capabilities can expose business data or execute ad-hoc SQL. Both are off by default and require explicit opt-in env vars, so the operator makes a deliberate decision before they are reachable:
| Capability | Env var | Default | Policy note |
|---|---|---|---|
Table previews (SAPRead(type=TABLE_CONTENTS/TABLE_QUERY)), saved SAPscript texts and SLG1 messages (SAPQuery actions long_text / application_log) | SAP_ALLOW_DATA_PREVIEW=true | false (off) | Reads application data; authenticated callers also need data scope. |
Freestyle ABAP SQL (SAPQuery(action=sql)) | SAP_ALLOW_FREE_SQL=true | false (off) | Executes ad-hoc ABAP SQL; authenticated callers also need sql scope. |
| Exact source blocklist (experimental) | SAP_BLOCKED_DATA_SOURCES=USR02,PA0002 | empty (off) | Denies exact direct/transitive table or CDS dependencies; active mode is deliberately fail-closed and slower. |
When either capability is enabled, successful data-preview bodies are limited cumulatively per tool call (2 MiB by default), and only two data-result calls per process remain admitted through parsing and serialization. SAPQuery.maxRows is separately clamped to 10,000, but wide rows can reach the byte limit much earlier. See Configuration before tuning ARC1_MAX_DATAPREVIEW_RESPONSE_BYTES or ARC1_MAX_CONCURRENT_DATA_RESULTS.
With both flags at their defaults, ARC-1's data/sql rows are unreachable. FAQ Q33 excludes application-table reads, business-data export and backend SQL from ADT's intended development-tooling scope. Keep these flags off unless the specific use has a documented allowance or SAP authorization under the applicable agreements; internal approval or a technical opt-in alone is insufficient. Use Published business APIs for business-data integration.
ARC-1 combines capability discovery with conservative defaults and centralized authorization. Discovery establishes technical availability, not API-policy permission. Follow the reference architecture and verify both the API-specific allowance and the deployed controls.
Versioning & Stability
From 1.0 onward ARC-1 follows semantic versioning: patch releases fix bugs, minor releases add backward-compatible capability, and breaking changes to the MCP tool surface, configuration, or auth contract bump the major version.
Experimental, default-off features are excluded from this guarantee until they are promoted — they are clearly labeled and their surface may still change in a minor release. Today this covers the multi-target BTP mode (ADR-0006 / ADR-0007) and the data-source blocklist.
What changed per release: the annotated Release Notes give each release its impact and upgrade action; CHANGELOG.md lists every merged PR.
Quick Start
Install as an Agent Plugin — one portable install for the MCP server and all bundled SAP skills in GitHub Copilot, VS Code, Cursor, Codex, and other compatible clients:
copilot plugin marketplace add arc-mcp/arc-1
copilot plugin install arc-1@arc-1Agent Plugins 1.0 does not define secret prompts, so create the ARC-1 .env in the installed plugin's persistent data directory before connecting to SAP. See the [Agent Plugin guide](https://docs.arc-1-mcp.com/agent-plugin/) for client-specific installation, safe configuration, and verification.
Install in Claude — pick your surface (full guide: Install in Claude):
- Claude Desktop — download the latest
arc-1-*.mcpbfrom Releases and double-click it (or Settings → Extensions). Claude prompts for your SAP connection. (The.mcpbis attached to releases automatically; if the newest one doesn't have it yet, see Install in Claude.) - Claude Code — one install for the MCP server and all SAP skills:
/plugin marketplace add arc-mcp/arc-1
/plugin install arc-1@arc-1- Any MCP client / manual — run it directly:
npx arc-1@latest --url https://your-sap-host:44300 --user YOUR_USER- Trying it out on your laptop? → Quickstart
- Full local dev setup (Docker, cookie extractor, client configs)? → Local Development
- Deploying for a team / BTP? → Deployment
Blog Series — AI ABAP Development
A long-form series on blog.zeis.de covering AI for ABAP development, ARC-1's design, and real-world walkthroughs:
- How I Use AI for Development and Why Context Matters
- ABAP and Agentic AI: The Hidden Problem in Real Projects
- Introducing ARC-1: A Secure ADT MCP Server for Enterprise SAP Development
- ARC-1 on SAP BTP: Secure ABAP Agentic Development Beyond the Laptop
- ARC-1 with Copilot Studio: SAP System Context Beyond Developers
- ARC-1 with Joule Studio: Bringing Real ABAP System Context into Joule
- From SEGW and Legacy UI5 to RAP with ARC-1
Full list and new posts → [blog.zeis.de/tags/ai-abap-development-series](https://blog.zeis.de/tags/ai-abap-development-series/).
Documentation
Full documentation is available at [docs.arc-1-mcp.com](https://docs.arc-1-mcp.com/).
| Guide | Description |
|---|---|
| Quickstart | 5-minute npx + Claude Desktop setup |
| Agent Plugin | Portable server + all skills for Copilot, VS Code, Cursor, Codex, and compatible clients |
| Install in Claude | Desktop .mcpb, Claude Code plugin (server + skills), and remote BTP connector |
| Local Development | Full local dev — all install methods, MCP client configs, SSO cookie extractor |
| Deployment | Multi-user deployment — Docker, BTP Cloud Foundry, BTP ABAP |
| SAP BTP: Start Here | Choose the BTP topology and follow the correct deployment, auth, destination, and operations guides |
| BTP Cloud Foundry | MTA deployment, topology decision, role handoffs, and safe acceptance |
| BTP Administration | Changes, roles, secrets, scaling, upgrades, rollback, and customer handover |
| Multi-System Setup | BTP multi-target deployment, destinations, roles, and scoped pinned PP writes |
| Configuration | Every flag and env var, one table |
| Updating | Update procedures per install method |
| Enterprise Auth | Layer A / Layer B auth internals, coexistence matrix |
| Tool Reference | Complete reference for all 12 tools |
| Extensions (Custom Tools) | Add your own Custom_* tools without forking (FEAT-61) — reads, gated non-ADT writes, class/report execute |
| Architecture | System architecture with diagrams |
| AI Usage Patterns | Agent workflow patterns and best practices |
| Skills | Reusable ARC-1 agent skills, including GitHub Copilot in Eclipse and VS Code ADT setup |
| Blog Series | Long-form posts on AI for ABAP development, ARC-1 internals, and real-world walkthroughs |
Development
npm ci && npm run build && npm testSee CLAUDE.md for codebase structure, testing commands, and contribution guidelines.
Credits
| Project | Author | Contribution |
|---|---|---|
| vibing-steampunk | oisee | Original Go MCP server — ARC-1's starting point |
| abap-adt-api | Marcello Urbani | TypeScript ADT library, definitive API reference |
| mcp-abap-adt | Mario Andreschak | First MCP server for ABAP ADT |
| abaplint | Lars Hvam | ABAP parser/linter (used via @abaplint/core) |
License
MIT