ARC-1

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 example SAPWrite.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 requires SAP_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-writes and --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, or admin per 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_LIMIT overrides it), per-user MCP quota (Layer 2, off by default — multi-user deployments opt in via ARC1_RATE_LIMIT=60), and a server-wide SAP-bound semaphore (Layer 3, default 10, on). Honors Retry-After on 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 OAuth2UserTokenExchange for 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 SAPRead for exact implementation behavior. For business purpose, reviews or test design, start with SAPContext(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 confirms 304 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 — SAPRead accepts version="active" | "inactive" | "auto" and warns when the active source has an unactivated draft.
• Write invalidation — when SAPWrite or SAPActivate mutates 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 (104 unit 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 22 and 24; 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:

| SAPWrite | Create/update/delete ABAP source and DDIC metadata with automatic lock/unlock (PROG, CLAS, INTF, FU