ARC-1 Roadmap¶
Last Updated: 2026-04-04 Project: ARC-1 (ABAP Relay Connector) — MCP Server for SAP ABAP Systems Repository: https://github.com/marianfoo/arc-1
Vision¶
Every other SAP MCP server today runs on the developer's local machine — unmanaged, unaudited, with whatever permissions the developer happens to have. There is no admin oversight, no token budget control, no audit trail, and no way to restrict what an LLM can do to an SAP system.
ARC-1 is different. It is a centralized, admin-controlled MCP gateway deployed on BTP Cloud Foundry or a company server (Docker). One instance per SAP system, serving multiple users. The admin controls which tools are exposed, which packages can be touched, and whether writes are allowed — before any LLM request reaches SAP.
Core Design Principles¶
-
Centralized admin control — ARC-1 runs as a managed service, not on developer laptops. Admins configure safety gates (read-only, package allowlists, operation filters, SQL blocking, transport guards) per instance. Every tool call is audited with user identity. Developers and LLMs operate within guardrails set by the organization — not by individual choice.
-
Per-user SAP identity — Principal propagation maps each MCP user to their own SAP user via BTP Destination Service + Cloud Connector. SAP's native authorization (S_DEVELOP, package checks) applies per user. No shared service accounts, no credential leakage. The LLM acts with exactly the permissions the SAP user has — nothing more.
-
Token-efficient tool design — 11 intent-based tools (~5K schema tokens) instead of 200+ individual endpoints. This isn't just cleaner — it's the difference between working and not working on mid-tier LLMs (GPT-4o-mini, Gemini Flash, Copilot Studio). Hyperfocused mode reduces to 1 tool (~200 tokens). Method-level surgery and context compression (7-30x) keep responses within tight context windows.
-
BTP-native deployment — Designed for SAP BTP Cloud Foundry with Destination Service, Cloud Connector, XSUAA OAuth, and BTP Audit Log Service. Also deployable as Docker on any server. Local stdio mode is supported for development and testing, but the production target is always a centralized instance.
-
Multi-client, vendor-neutral — Works with any MCP-compatible client: Claude Code/Desktop, Microsoft Copilot Studio, VS Code (GitHub Copilot), Gemini CLI, Cursor, and others. The same ARC-1 instance serves all of them. Three auth modes coexist (XSUAA + OIDC/Entra ID + API key) so different client types connect through the same gateway.
-
Safe defaults, opt-in power — Read-only by default. Free SQL blocked by default. No write operations until the admin explicitly enables them. This inverts the model of every other MCP server where everything is allowed until someone thinks to restrict it.
Current State (v0.3.0 — TypeScript)¶
| Area | Status |
|---|---|
| TypeScript Migration | ✅ Complete — Go code removed, pure TypeScript |
| Core MCP Server | ✅ 11 intent-based tools + hyperfocused mode (1 tool), HTTP Streamable + stdio |
| Safety System | ✅ Read-only, package filter, operation filter, transport guard, dry-run |
| Phase 1: API Key Auth | ✅ ARC1_API_KEY Bearer token |
| Phase 2: OAuth/OIDC (Entra ID) | ✅ JWT validation via jose library, tested with Copilot Studio |
| Phase 4: BTP CF Deployment | ✅ Docker on CF with Destination Service + Cloud Connector |
| BTP Destination Service | ✅ Auto-resolves SAP credentials from BTP Destination at startup |
| BTP Connectivity Proxy | ✅ Routes through Cloud Connector with JWT Proxy-Authorization |
| BTP ABAP Environment | ✅ OAuth 2.0 browser login, direct connectivity |
| ABAP Linter | ✅ @abaplint/core integration (full abaplint rules) |
| Docker Image | ✅ Multi-platform (amd64/arm64), GHCR ghcr.io/marianfoo/arc-1 |
| CI/CD | ✅ GitHub Actions: lint + typecheck + unit tests (Node 20/22) + integration tests |
| XSUAA OAuth Proxy | ✅ MCP SDK ProxyOAuthServerProvider + @sap/xssec JWT validation |
| Scope Enforcement | ✅ Per-tool scope checks (read/write/admin), ListTools filtered by scope |
| Audit Logging | ✅ User identity in tool call logs, BTP Audit Log sink, file sink |
| MCP Elicitation | ✅ Interactive parameter collection for destructive ops |
| Dynamic Client Registration | ✅ /register endpoint for MCP clients (RFC 7591) |
| Principal Propagation | ✅ Per-user ADT client via BTP Destination Service + Cloud Connector |
| Hyperfocused Mode | ✅ Single SAP tool (~200 tokens) — competitive parity with VSP |
| Method-Level Surgery | ✅ edit_method in SAPWrite, list_methods/get_method in SAPContext (95% token reduction) |
| Runtime Diagnostics | ✅ SAPDiagnose — short dumps (ST22), ABAP profiler traces |
| DDIC Completeness | ✅ Structures, domains, data elements, DDLX, transactions, BOR objects, T100 messages |
| RAP CRUD | ✅ DDLS, DDLX, BDEF, SRVD write + SRVB read |
| Context Compression | ✅ SAPContext with AST-based dependency extraction (7-30x reduction) |
| Test Coverage | ✅ 707+ unit tests + 28 BTP integration tests (vitest) |
| Documentation | ✅ Architecture, auth guides, Docker guide, setup phases |
Roadmap Items¶
Priority Legend¶
| Priority | Meaning |
|---|---|
| 🔴 P0 | Critical — blocks enterprise adoption |
| 🟠 P1 | High — significant value, should do next |
| 🟡 P2 | Medium — nice to have, plan for later |
| 🟢 P3 | Low — future consideration |
Effort Legend¶
| Effort | Meaning |
|---|---|
| XS | < 1 day |
| S | 1–2 days |
| M | 3–5 days |
| L | 1–2 weeks |
| XL | 2–4 weeks |
🔐 Security & Authentication¶
SEC-01: Principal Propagation — Per-User SAP Authentication¶
| Field | Value |
|---|---|
| Priority | 🔴 P0 |
| Effort | L (1–2 weeks: code wiring + SAP admin setup + testing) |
| Risk | Medium — requires SAP Basis admin (STRUST, CERTRULE, ICM profile) |
| Usefulness | Critical — enables per-user SAP authorization and audit trail |
| Status | ✅ Code complete (2026-03-27) — needs SAP-side setup (STRUST, CERTRULE, ICM) for end-to-end testing |
Implemented (2026-03-27) — BTP Cloud Connector approach (SEC-02 merged into SEC-01):
- lookupDestinationWithUserToken() in src/adt/btp.ts — calls Destination Service "Find Destination" API with X-User-Token header
- Per-request ADT client creation in src/server/server.ts — createPerUserClient() creates a fresh ADT client for each authenticated user
- SAP-Connectivity-Authentication header injection in src/adt/http.ts — carries SAML assertion to Cloud Connector
- SAP_PP_ENABLED=true config flag — opt-in for principal propagation
- Graceful fallback — if per-user lookup fails, falls back to shared service account
- No basic auth when PP active — username/password cleared, user identity from SAML assertion only
- 7 unit tests (5 BTP PP destination + 2 HTTP header injection)
Architecture flow:
1. User authenticates via XSUAA/OIDC → JWT token
2. MCP SDK passes authInfo.token to tool handler
3. ARC-1 calls Destination Service with X-User-Token: <jwt> header
4. Destination Service generates per-user auth tokens (SAML assertion)
5. ADT client sends SAP-Connectivity-Authentication header via connectivity proxy
6. Cloud Connector generates X.509 cert → CERTRULE → SAP user
7. SAP enforces S_DEVELOP authorization per user
SAP-side setup required (not yet done):
1. BTP Destination: Change authentication from BasicAuthentication to PrincipalPropagation
2. Cloud Connector: Synchronize trust with BTP subaccount, set principal type to X.509
3. SAP backend: STRUST (import Cloud Connector CA), CERTRULE, ICM params
4. Subject pattern: Map ${email} or ${user_name} to SAP user ID
References: - SAP Help: Configuring Principal Propagation - SAP Cloud SDK: On-Premise Connectivity - lemaiwo/btp-sap-odata-to-mcp-server — reference implementation
SEC-02: BTP Cloud Connector Principal Propagation¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | — |
| Risk | — |
| Usefulness | High — enables per-user auth when ARC-1 runs on BTP CF |
| Status | ✅ Merged into SEC-01 (2026-03-27) — code complete, SAP-side setup pending |
Merged: SEC-02 was implemented as part of SEC-01. The BTP Cloud Connector approach was chosen over direct X.509 cert generation because it leverages existing BTP infrastructure and requires less code in ARC-1. See SEC-01 for implementation details.
SEC-03: SAP Authorization Object Awareness (S_DEVELOP)¶
| Field | Value |
|---|---|
| Priority | — |
| Effort | — |
| Risk | — |
| Usefulness | — |
| Status | ✅ Subsumed by FEAT-16 (Error Intelligence) |
Merged: SEC-03's scope (parsing 403 authorization errors, mapping to S_DEVELOP objects, suggesting SU53/PFCG) is now part of FEAT-16 Error Intelligence, which covers all SAP error codes (403, 409, 423, 415) with actionable hints. See FEAT-16 for details.
SEC-04: Audit Logging¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | M (3–5 days) |
| Risk | Low |
| Usefulness | High — required for enterprise compliance |
| Status | ✅ Complete (2026-04-01) — multi-sink audit system with BTP Audit Log Service |
Implemented:
- src/server/audit.ts — central audit logger with pluggable sinks
- src/server/sinks/stderr.ts — stderr sink (default)
- src/server/sinks/file.ts — file sink for persistent audit trail
- src/server/sinks/btp-auditlog.ts — BTP Audit Log Service sink (enterprise compliance)
- User identity (userName, email, clientId) logged with every tool call
- Elicitation events (confirmations, user choices) logged
- Structured logger with text/JSON output and sensitive field redaction
References: - OWASP: MCP Server Security - Logging - Datadog: MCP Detection Rules
SEC-05: Rate Limiting¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — prevents runaway AI loops from overwhelming SAP |
| Status | Not started |
What: Token bucket rate limiter per MCP session, configurable via env var. Prevents an AI agent in a retry loop from generating thousands of SAP API calls per minute.
Configuration:
SAP_RATE_LIMIT=60 # requests per minute per session (0 = unlimited)
SAP_RATE_LIMIT_BURST=10 # burst allowance
Implementation:
- Use rate-limiter-flexible npm package or simple in-memory token bucket
- Per-session limiter (keyed by MCP session ID or OIDC user)
- Return MCP error with retry-after hint when rate limited
SEC-06: MCP Client Tool Restriction by User Role¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | M (3–5 days) |
| Risk | Medium — needs careful design |
| Usefulness | High — differentiates AI usage from Eclipse/ADT usage |
| Status | ✅ Complete via scope enforcement (2026-03-27) |
Implemented (2026-03-27):
- TOOL_SCOPES map in src/handlers/intent.ts — each tool requires a scope (read/write/admin)
- Scope enforcement in handleToolCall() — checks authInfo.scopes before executing any tool
- ListTools filtering in src/server/server.ts — users only see tools they have scopes for
- XSUAA role collections (ARC-1 Viewer/Editor/Admin) map to scopes via xs-security.json
- Additive to safety system — both scope check AND safety check must pass
- Backward compatible — no authInfo (stdio, simple API key) = no scope enforcement
- 12 unit tests covering all scope enforcement scenarios
How it works:
- read scope → SAPRead, SAPSearch, SAPQuery, SAPNavigate, SAPContext, SAPLint, SAPDiagnose (7 tools)
- write scope → adds SAPWrite, SAPActivate, SAPManage (10 tools)
- admin scope → adds SAPTransport (11 tools)
- XSUAA role collections assign scopes to users via BTP cockpit
Why this matters for basis admins: - An SAP developer user (with full S_DEVELOP in Eclipse) can be restricted to read-only via AI - The admin controls AI capabilities separately from SAP authorization - This is unique to ARC-1 — no other MCP server offers scope-based tool filtering
SEC-07: XSUAA OAuth Proxy for MCP-Native Clients (Claude, Cursor, MCP Inspector)¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | L (1–2 weeks) |
| Risk | Medium — requires careful OAuth flow implementation |
| Usefulness | Very High — enables Claude Desktop, Cursor, MCP Inspector to connect via BTP XSUAA |
| Status | ✅ Complete (2026-03-27) |
Implemented:
- MCP SDK's ProxyOAuthServerProvider proxies OAuth flow to XSUAA
- @sap/xssec v4.13+ for SAP-specific JWT validation (offline, JWKS cached)
- HTTP server refactored from node:http to Express 5 (required by MCP SDK auth)
- RFC 8414 discovery at /.well-known/oauth-authorization-server
- In-memory client store for dynamic client registration (RFC 7591)
- Chained token verifier: XSUAA → Entra ID OIDC → API key (all coexist)
- xs-security.json with read/write/admin scopes and 3 role collections
- XSUAA service instance created and bound on BTP CF
- Configuration: SAP_XSUAA_AUTH=true enables the proxy
Files:
- src/server/xsuaa.ts — OAuth provider, client store, chained verifier
- src/server/http.ts — Express-based HTTP server with auth routing
- xs-security.json — XSUAA service instance config
- docs/phase5-xsuaa-setup.md — Setup guide
Reference: Inspired by lemaiwo/btp-sap-odata-to-mcp-server.
🔧 Features & Tools¶
FEAT-01: Where-Used Analysis (Usage References)¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Very High — most requested missing feature |
| Status | Not started |
What: Find all references to an ABAP object across the system. Uses ADT endpoint /sap/bc/adt/repository/informationsystem/usageReferences.
Why: Currently ARC-1 has FindReferences (code intelligence, position-based), but not the repository-wide "Where-Used" analysis that every ABAP developer uses daily.
References: - Report 001: Feature Parity — Item #1
FEAT-02: API Release Status Tool (Clean Core)¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Very High — critical for S/4HANA Cloud and clean core compliance |
| Status | Not started |
What: Check whether an SAP object (class, function module, table, CDS view) is released, deprecated, or internal. Returns the API release state (C1 Released, C2 Deprecated, Not Released) and the recommended successor.
Why: Every S/4HANA Cloud / BTP ABAP customer needs to check if their code uses only released APIs. This is a "must have" for any AI copilot helping with ABAP Cloud development. The buettnerjulian/abap-adt-mcp competitor already has this.
FEAT-03: Enhancement Framework (BAdI/Enhancement Spot)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | M (3–5 days) |
| Risk | Low |
| Usefulness | Medium — important for customization scenarios |
| Status | Not started |
What: Read enhancement spots, BAdI definitions, and enhancement implementations. Uses ADT endpoints /sap/bc/adt/enhancements/*.
FEAT-04: DDIC Object Support (Domains, Data Elements, DDLX)¶
| Field | Value |
|---|---|
| Priority | — |
| Effort | — |
| Risk | — |
| Usefulness | — |
| Status | ✅ Complete (2026-04-01) |
Implemented: Read support for domains (DOMA), data elements (DTEL), structures (STRU), CDS metadata extensions (DDLX), and transactions (TRAN) in SAPRead. Structured metadata output with type info, labels, value tables, search help. Write support for DDLS, DDLX, BDEF, SRVD via SAPWrite.
FEAT-05: Code Refactoring (Rename, Extract Method)¶
| Field | Value |
|---|---|
| Priority | 🟢 P3 |
| Effort | L (1–2 weeks) |
| Risk | Medium — complex ADT API interactions |
| Usefulness | Medium — valuable but complex |
| Status | Not started |
What: ADT supports code refactoring operations (rename symbol, extract method, change package). The marcellourbani/abap-adt-api TypeScript library implements these.
FEAT-06: Cloud Readiness Assessment¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | M (3–5 days) |
| Risk | Low |
| Usefulness | High — unique differentiator for S/4HANA migration |
| Status | Not started |
What: Run ATC checks with ABAP Cloud check variant to assess whether code is cloud-ready. Combined with the ABAP linter (@abaplint/core integration in src/lint/lint.ts), provide a comprehensive clean core compliance report.
Why: AWS ABAP Accelerator has this as a key feature. ARC-1 combines ATC cloud checks with @abaplint/core for offline linting.
FEAT-07: TLS/HTTPS for HTTP Streamable Transport¶
| Field | Value |
|---|---|
| Priority | 🔴 P0 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | High — required for production enterprise deployments without reverse proxy |
| Status | Not started |
| Source | fr0ster tracker: TLS evaluation |
What: Add native TLS support to the HTTP Streamable transport. fr0ster added this in v4.6.0 with --tls-cert/--tls-key flags. Currently ARC-1 requires a reverse proxy (nginx, CF router) for HTTPS.
Why: Enterprise customers deploying outside BTP CF (e.g., on VMs, Kubernetes) need HTTPS without an external proxy. fr0ster's implementation shows the pattern: load cert/key files, create https.Server instead of http.Server.
Implementation:
- Add SAP_TLS_CERT / SAP_TLS_KEY env vars (and --tls-cert / --tls-key CLI flags)
- In src/server/http.ts, conditionally create https.createServer() when cert/key are provided
- Auto-detect port 443 vs 8080 based on TLS mode
FEAT-08: Content-Type 415/406 Auto-Retry¶
| Field | Value |
|---|---|
| Priority | 🔴 P0 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | High — robustness fix for SAP system variations |
| Status | Not started |
| Source | fr0ster tracker: 415 evaluation, VSP tracker: issue #9 |
What: SAP systems vary in Accept/Content-Type expectations across versions and endpoint types. When a request gets 415 (Unsupported Media Type) or 406 (Not Acceptable), automatically retry with alternative Content-Type headers.
Why: Both fr0ster (issue #22/#23) and VSP (issue #9) hit this on transport endpoints. It's a common SAP ADT compatibility issue across system versions. A transparent retry in src/adt/http.ts would handle it for all endpoints.
Implementation:
- In src/adt/http.ts, intercept 415/406 responses
- Retry with Accept: application/xml → Accept: */* (or vice versa)
- Retry with Content-Type: application/xml → text/plain for transport endpoints
- Max 1 retry, log the fallback
FEAT-09: SQL Trace Monitoring¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — performance diagnostics |
| Status | Not started |
| Source | Feature matrix #17 |
What: Read SQL trace state, list SQL traces, analyze trace results. Uses ADT endpoints /sap/bc/adt/runtime/traces/sql/*. VSP has GetSQLTraceState, ListSQLTraces.
Why: Completes the diagnostics story alongside short dumps and profiler traces. Useful for AI-assisted performance analysis.
FEAT-10: PrettyPrint (Code Formatting)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Medium — code formatting via ADT API |
| Status | Not started |
| Source | Feature matrix #14 |
What: Format ABAP source code via ADT's PrettyPrint API. VSP and mcp-abap-abap-adt-api have this. Also includes get/set PrettyPrinter settings.
FEAT-11: Inactive Objects List¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Medium — development workflow improvement |
| Status | Not started |
| Source | Feature matrix #19 |
What: List inactive objects system-wide. VSP and fr0ster both have this. Uses /sap/bc/adt/activation/inactive.
FEAT-12: Fix Proposals / Auto-Fix from ATC¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | High — safer than LLM-guessed fixes |
| Status | Not started |
| Source | abap-adt-api eval |
What: When ATC or syntax check finds an issue, SAP's fix proposal API (/sap/bc/adt/quickfixes) suggests the exact correction. Expose this via SAPDiagnose or SAPWrite so the LLM can apply verified fixes instead of guessing.
Why: Far safer than having the LLM guess the fix. Directly supports safe defaults and token efficiency — the LLM gets the exact fix without trial-and-error. The abap-adt-api library implements fixProposals and fixEdits.
FEAT-13: DDIC Domain/Data Element Write¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | High — completes AI-assisted data modeling |
| Status | Not started |
| Source | abap-adt-api eval |
What: ARC-1 reads DOMA/DTEL but can't write properties or fixed values. The abap-adt-api library (v7.1.1) added createDomainDefinition, createDataElement, and createStructure with full property support. Add write support for these in SAPWrite.
Why: Blocks full AI-assisted data modeling workflows. A developer asking the LLM to "create a domain ZSTATUS with values A=Active, I=Inactive" currently can't be fulfilled end-to-end.
FEAT-14: 401 Session Timeout Auto-Retry¶
| Field | Value |
|---|---|
| Priority | 🔴 P0 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | High — prevents mid-conversation failures |
| Status | Not started |
| Source | VSP eval |
What: After idle, SAP returns 401. ARC-1 handles CSRF 403 refresh but may not handle 401 session timeout. Add silent re-authentication and retry on 401 in src/adt/http.ts.
Why: Mid-conversation failures are disruptive to LLM workflows. VSP (#32) and abap-adt-api both handle this. A centralized gateway that stays idle between user requests will hit this frequently.
FEAT-15: Namespace URL Encoding Audit¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | High — prevents hard-to-debug failures |
| Status | Not started |
| Source | VSP eval, VSP eval |
What: Namespaced objects (/NAMESPACE/CLASS) fail if / is not correctly encoded in ADT URLs. VSP hit this in issues #18, #52. Audit all encodeURIComponent usage in src/adt/client.ts and src/adt/http.ts.
FEAT-16: Error Intelligence (Actionable Hints)¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | High — directly improves admin control and LLM UX |
| Status | Not started |
| Source | Dassian pattern, Roadmap SEC-03 |
What: When SAP returns common errors (409 locked, 423 enqueued, 403 auth, 415 content type), return actionable hints: "Object locked by user X — check SM12", "Authorization failed — check SU53/PFCG", "Transport required — check SE09". Subsumes SEC-03 (S_DEVELOP awareness).
Why: Supports centralized admin control — admins and LLMs get clear guidance instead of raw SAP error HTML. Dassian does this well with its error intelligence pattern.
FEAT-17: Type Auto-Mappings for SAPWrite¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Medium — reduces LLM confusion |
| Status | Not started |
| Source | Dassian pattern |
What: Auto-map friendly type codes to ADT internal codes: CLAS → CLAS/OC, INTF → INTF/OI, PROG → PROG/P, etc. LLMs shouldn't need to know ADT's internal type code suffixes.
Why: Supports token efficiency — reduces failed create attempts where the LLM guesses the wrong type code.
FEAT-18: Function Group Bulk Fetch¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | High — significant token/round-trip savings |
| Status | Not started |
| Source | Dassian pattern |
What: Fetch ALL includes and function modules of a function group in one call, instead of N sequential requests. Returns combined source with clear delimiters.
Why: Supports token efficiency — a function group with 20 FMs currently requires 20+ round trips. One bulk call reduces latency and simplifies the LLM's context.
FEAT-19: Transport Contents (E071 List)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Medium — show objects inside a transport request |
| Status | Not started |
| Source | Dassian pattern, abap-adt-api |
What: List the objects (E071 entries) contained in a transport request. Both dassian and abap-adt-api support this. Useful for reviewing what an LLM has changed before release.
FEAT-20: Source Version / Revision History¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — version comparison, rollback context |
| Status | Not started |
| Source | abap-adt-api eval |
What: Load specific versions of ABAP source, compare active vs inactive, view revision history. The abap-adt-api library (v6.0.0) added loadSourceVersion and sourceVersions. Enables "show me what changed" and rollback workflows.
FEAT-21: ABAP Documentation (F1 Help)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Medium — LLM fetches real docs instead of hallucinating |
| Status | Not started |
| Source | abap-adt-api eval, VSP |
What: Fetch official ABAP keyword documentation (F1 help) via ADT API. The abap-adt-api library (v7.1.0) added abapDocumentation. Lets the LLM look up correct syntax instead of guessing.
FEAT-22: gCTS/abapGit Integration¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | M (3–5 days) |
| Risk | Low |
| Usefulness | Medium — Git-based ABAP workflows |
| Status | Not started |
| Source | Dassian, VSP, abap-adt-api |
What: List Git repositories, pull changes, check repo status. Multiple competitors have this (VSP, dassian, abap-adt-api). Enables Git-based ABAP development workflows.
FEAT-23: GetProgFullCode (Include Traversal)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — reduces round trips for programs with includes |
| Status | Not started |
| Source | fr0ster |
What: Fetch a program with all its includes resolved into a single response. fr0ster has GetProgFullCode. Reduces N+1 round trips when reading programs with many includes.
FEAT-24: CompareSource (Diff)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — diff two versions of source |
| Status | Not started |
| Source | VSP |
What: Diff two versions of ABAP source (active vs inactive, or across transports). VSP has CompareSource. Useful for code review workflows.
FEAT-25: CDS Unit Tests¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — CDS test-driven development |
| Status | Not started |
| Source | fr0ster |
What: Create, run, and check CDS unit tests. fr0ster is the only project with this capability. Enables AI-assisted CDS development with test coverage.
FEAT-26: MCP Client Config Snippets¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — great onboarding UX |
| Status | Not started |
| Source | fr0ster eval |
What: arc-1 config --client claude prints ready-to-paste MCP client configuration. fr0ster supports 11 clients. Lowers the barrier to first connection.
FEAT-27: Migration Analysis (ECC→S/4)¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Medium — custom code migration check |
| Status | Not started |
| Source | AWS ABAP Accelerator |
What: Run custom code migration checks to identify ECC code that needs changes for S/4HANA. AWS ABAP Accelerator has this as a key feature. Complements FEAT-06 (Cloud Readiness Assessment).
FEAT-28: SAP Compatibility Hardening¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days total) |
| Risk | Low |
| Usefulness | Medium — prevents edge-case failures across SAP versions |
| Status | Not started |
| Source | Multiple competitor trackers |
What: A bundle of small compatibility fixes identified across all competitor trackers:
1. ATC ciCheckFlavour workaround — older SAP systems don't support the ciCheckFlavour parameter (dassian pattern)
2. Stateful session header — some ADT endpoints require X-sap-adt-sessiontype: stateful (abap-adt-api eval)
3. Include lock parent resolution — includes inherit parent's lock; verify FUGR/PROG includes lock correctly (abap-adt-api eval)
4. Ignore syntax warnings on save — syntax warnings should not block saves (VSP eval)
5. Transport endpoint S/4 compat — transport creation endpoint differs on S/4HANA 757+ (VSP eval)
FEAT-29: P3 Backlog (Future / Niche)¶
The following features are tracked but not planned for near-term implementation. They are niche, complex, or not aligned with core principles.
| ID | Feature | Why deferred | Source | Effort |
|---|---|---|---|---|
| 29a | SSE transport | Most MCP clients use stdio or HTTP Streamable | fr0ster | M |
| 29b | ABAP debugger (8+ tools) | Requires WebSocket + ZADT_VSP deployment | VSP | L |
| 29c | Execute ABAP (IF_OO_ADT_CLASSRUN) | Security risk — needs careful safety gating | VSP, dassian | S |
| 29d | Call graph analysis (5 tools) | Useful but niche, complex | VSP | M |
| 29e | UI5/Fiori BSP CRUD (7 tools) | Only relevant if UI5 detected | VSP | M |
| 29f | RFC connectivity (sap-rfc-lite) | Alternative to ADT HTTP, niche | fr0ster | M |
| 29g | Embeddable server mode | Library mode for CAP/Express embedding | fr0ster | S |
| 29h | Lock registry with recovery | Persist lock state to disk for crash recovery | fr0ster | M |
| 29i | Language attributes on creation | Multi-language object creation | abap-adt-api eval | XS |
| 29j | Lua scripting / WASM compiler | VSP-unique experimental, not core MCP value | VSP | N/A |
🏗️ Infrastructure & Operations¶
OPS-01: Structured JSON Logging¶
| Field | Value |
|---|---|
| Priority | — |
| Effort | — |
| Risk | — |
| Usefulness | — |
| Status | ✅ Complete — src/server/logger.ts + src/server/audit.ts with multi-sink output |
Implemented: Structured logger with text/JSON output, sensitive field redaction. Multi-sink audit system (stderr, file, BTP Audit Log Service). User identity from OIDC JWT in all log entries.
OPS-02: Health Check Enhancements¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | XS (< 1 day) |
| Risk | Low |
| Usefulness | Medium — better monitoring |
| Status | Basic /health exists |
What: Enhanced health endpoint that checks SAP connectivity, returns version info, uptime, feature availability. Separate /health (load balancer, always fast) from /health/deep (includes SAP connectivity check).
OPS-03: Multi-System Routing¶
| Field | Value |
|---|---|
| Priority | 🟢 P3 |
| Effort | L (1–2 weeks) |
| Risk | Medium — significant architecture change |
| Usefulness | Medium — needed for enterprises with multiple SAP systems |
| Status | Not started |
What: Support multiple SAP systems from a single ARC-1 instance. Each MCP request includes a sap_system_id parameter. ARC-1 routes to the appropriate system based on configuration.
OPS-04: GitHub Actions CI/CD Pipeline¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | — |
| Risk | — |
| Usefulness | High — automated testing and image publishing |
| Status | ✅ Complete |
Implemented:
- .github/workflows/test.yml — lint + typecheck + unit tests (Node 20/22) on every push/PR, integration tests on main
- .github/workflows/docker.yml — multi-platform Docker build (amd64/arm64) to GHCR on tags + manual dispatch
- .github/workflows/release.yml — npm publish with provenance on version tags
📖 Documentation & Ecosystem¶
DOC-01: End-to-End Copilot Studio Setup Guide¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Very High — critical for adoption |
| Status | Partially done (phase2-oauth-setup.md updated with Copilot Studio section) |
What: Complete guide with screenshots covering:
1. Entra ID app registration (step-by-step)
2. BTP CF deployment (manifest, cf push, env vars)
3. Power Automate custom connector creation (Security tab configuration)
4. Copilot Studio agent creation with ARC-1 as MCP server
5. Common errors and fixes (troubleshooting table with all AADSTS errors)
DOC-02: Basis Admin Security Guide¶
| Field | Value |
|---|---|
| Priority | 🟠 P1 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | Very High — SAP Basis admins need clear guidance |
| Status | Not started |
What: Dedicated guide for SAP Basis administrators covering: - What ARC-1 does and doesn't do (it's a proxy, not an ABAP runtime) - SAP-side authorization: S_DEVELOP, ICF service activation for ADT - Safety controls: read-only mode, allowed packages, operation filters - How to create a restricted technical user for ARC-1 (minimal S_DEVELOP authorization) - How to set up STRUST/CERTRULE for principal propagation - Monitoring: where to check SAP security audit log (SM20) for ARC-1 activity - How ARC-1's safety layer complements SAP's native authorization
DOC-03: SAP Community Blog Post¶
| Field | Value |
|---|---|
| Priority | 🟡 P2 |
| Effort | S (1–2 days) |
| Risk | Low |
| Usefulness | High — visibility and adoption |
| Status | Draft exists (Report 023) |
What: Publish on SAP Community: "ARC-1: Connecting SAP ABAP to Microsoft Copilot Studio via MCP" covering architecture, security model, and setup.
🧹 Code Cleanup & Technical Debt¶
CLEAN-01: Go Code Removal¶
| Field | Value |
|---|---|
| Priority | — |
| Effort | — |
| Risk | — |
| Usefulness | — |
| Status | ✅ Complete — all Go source removed (cmd/, internal/, pkg/, go.mod, go.sum, Makefile) |
CLEAN-02: CLI Surface¶
| Field | Value |
|---|---|
| Priority | — |
| Effort | — |
| Risk | — |
| Usefulness | — |
| Status | ✅ Complete — minimal CLI: arc1 search, arc1 source, arc1 lint, arc1 serve |
Prioritized Execution Order¶
Priorities are assigned based on which core design principle a feature serves. Sourced from 3 competitor trackers (fr0ster, VSP, abap-adt-api) and the cross-project feature matrix.
Phase A: Production Blockers (P0)¶
- FEAT-08 Content-Type 415/406 Auto-Retry (XS) — both fr0ster and VSP hit this
- FEAT-14 401 Session Timeout Auto-Retry (XS) — centralized gateway idles between requests
- FEAT-07 TLS/HTTPS for HTTP Streamable (S) — enterprise deployments without reverse proxy
- FEAT-15 Namespace URL Encoding Audit (XS) — silent failures for namespaced objects
Phase B: Core Value Features (P1)¶
- FEAT-01 Where-Used Analysis (XS) — most requested, daily ABAP developer need
- FEAT-17 Type Auto-Mappings for SAPWrite (XS) — eliminate LLM type code confusion
- FEAT-02 API Release Status / Clean Core (S) — must-have for S/4HANA Cloud
- FEAT-12 Fix Proposals / Auto-Fix (S) — safer than LLM-guessed fixes
- FEAT-16 Error Intelligence (S) — actionable hints for SAP errors (subsumes SEC-03)
- FEAT-13 DDIC Domain/Data Element Write (S) — complete data modeling workflow
- FEAT-18 Function Group Bulk Fetch (S) — token/round-trip savings
- DOC-01 Copilot Studio Setup Guide (S) — critical for enterprise adoption
- DOC-02 Basis Admin Security Guide (S) — admin audience needs clear guidance
Phase C: ADT Feature Parity (P2) — Quick Wins¶
- FEAT-10 PrettyPrint (XS) — code formatting, VSP and abap-adt-api have it
- FEAT-11 Inactive Objects List (XS) — development workflow
- FEAT-19 Transport Contents (XS) — review objects before release
- FEAT-21 ABAP Documentation / F1 Help (XS) — real docs instead of hallucination
- FEAT-28 SAP Compatibility Hardening (S) — 5 compat fixes bundled
- OPS-02 Health Check Enhancements (XS) —
/health/deepwith SAP connectivity check
Phase D: ADT Feature Parity (P2) — Larger Items¶
- FEAT-09 SQL Trace Monitoring (S) — completes diagnostics story
- SEC-05 Rate Limiting (S) — prevent runaway AI loops
- FEAT-20 Source Version / Revision History (S) — version comparison, rollback
- FEAT-24 CompareSource / Diff (S) — code review workflows
- FEAT-26 MCP Client Config Snippets (S) — onboarding UX
- FEAT-25 CDS Unit Tests (S) — CDS test-driven development
- FEAT-23 GetProgFullCode / Include Traversal (S) — reduce round trips
- FEAT-27 Migration Analysis ECC→S/4 (S) — custom code migration
- FEAT-06 Cloud Readiness Assessment (M) — ATC cloud checks + abaplint
- FEAT-03 Enhancement Framework / BAdI (M) — customization scenarios
- FEAT-22 gCTS/abapGit Integration (M) — Git-based ABAP workflows
- OPS-03 Multi-System Routing (L) — one instance → multiple SAP systems
- DOC-03 SAP Community Blog Post (S) — visibility and adoption
Phase E: Future / Niche (P3)¶
- FEAT-05 Code Refactoring (L) — rename, extract method, change package
- FEAT-29 P3 Backlog — see FEAT-29 table for SSE, debugger, execute ABAP, call graph, UI5/BSP, RFC, embeddable server, lock registry, language attributes
Competitive Landscape¶
Detailed tracking: See
compare/for per-commit and per-issue evaluations of key competitors.
| Competitor | Language | Tools | Auth | Safety | Deployment | Key Advantage |
|---|---|---|---|---|---|---|
| ARC-1 | TypeScript | 11 intent-based + hyperfocused | API Key, OIDC, XSUAA, PP | Read-only, pkg filter, op filter, scope enforcement | Docker, BTP CF, npm | Per-user PP, scope-based tools, 3 auth modes, safety, 707+ tests |
| vibing-steampunk | Go 1.24 | 1-99 (3 modes) | Basic, Cookie | Op filter, pkg filter, transport guard | Go binary (9 platforms) | 242 stars, native ABAP parser, WASM compiler, Lua scripting |
| fr0ster/mcp-abap-adt | TypeScript | 287 (4 tiers) | 9 providers (incl. TLS, SAML, Device Flow) | Exposition tiers | npm @mcp-abap-adt/core |
Most tools, most auth options, embeddable, RFC, multi-system |
| SAP ABAP Add-on MCP | ABAP | ~10 | SAP native | SAP authorization | Runs inside SAP | No proxy needed, SAP-native auth |
| lemaiwo/btp-sap-odata-to-mcp-server | TypeScript | ~10 | XSUAA OAuth proxy | XSUAA roles | BTP CF (MTA) | XSUAA OAuth proxy, principal propagation |
| dassian-adt / abap-mcpb | JavaScript | 25 | Basic, Browser login | MCP elicitation | Node.js / MCPB | Error intelligence, type auto-mappings, 7 elicitation flows |
| AWS ABAP Accelerator | Python | ~15 | OAuth, X.509 | Basic | AWS Lambda | Cloud readiness assessment, migration |
ARC-1 differentiators (no other project has all of these): 1. Intent-based routing — 11 tools vs 25-287, simplest LLM decision surface 2. Principal propagation — per-user SAP authentication via BTP Destination Service + Cloud Connector 3. Scope-based tool filtering — users only see tools they have permission for (read/write/admin via XSUAA roles) 4. Three auth modes coexist — XSUAA OAuth + Entra ID OIDC + API key on the same endpoint 5. Comprehensive safety system — read-only, package filter, operation filter, transport guard, dry-run — additive to scopes 6. Multi-sink audit logging — stderr + file + BTP Audit Log Service 7. Context compression + method-level surgery — AST-based 7-30x + 95% method-level reduction 8. MCP elicitation — interactive confirmations for destructive operations 9. 707+ automated tests with CI on Node 20/22, BTP integration tests 10. npm + Docker + release-please — most professional distribution pipeline
Key competitive threats (tracked in compare/):
1. vibing-steampunk (242 stars) — community favorite, daily commits, expanding into compilers/scripting. Lacks enterprise auth but developer-loved.
2. fr0ster (v4.8.1, 85+ releases in 5 months) — fastest-moving competitor. 9 auth providers, TLS, RFC, embeddable. Watch for convergence on enterprise features.
3. btp-odata-mcp (119 stars) — different category (OData) but high adoption. Could expand into ADT territory.
Key References¶
Internal Reports¶
- Enterprise Copilot Studio Plan
- Feature Parity Analysis
- Enterprise Bridge Gap Analysis
- Enterprise Auth Research
- Centralized Auth Architecture
- BTP Deployment Report
External References & Implementations¶
- lemaiwo/btp-sap-odata-to-mcp-server — TypeScript MCP server with XSUAA OAuth proxy, BTP Destination Service, principal propagation
- MCP Specification — Authorization
- RFC 9728 — OAuth Protected Resource Metadata
- OWASP Secure MCP Server Development Guide
- SAP Help: Principal Propagation
- SAP Help: S_DEVELOP Authorization Object
- Microsoft: Copilot Studio Custom Connectors
🔄 TypeScript Migration — Complete¶
STRAT-01: TypeScript Migration¶
| Field | Value |
|---|---|
| Priority | — |
| Status | ✅ Complete (2026-03-26) |
What was done:
- Full Go → TypeScript migration in a single session
- Custom ADT HTTP client (axios-based, CSRF lifecycle, cookie persistence, session isolation)
- 11 intent-based tools ported with identical behavior
- Safety system ported (read-only, package filter, operation filter, transport guard)
- HTTP Streamable transport with per-request server isolation (Copilot Studio compatible)
- API key + OIDC/JWT authentication (jose library)
- BTP Destination Service integration (VCAP_SERVICES parsing, destination lookup, connectivity proxy)
- @abaplint/core integration (replaces custom Go ABAP lexer with full abaplint rules)
- better-sqlite3 + in-memory cache (replaces Go CGO/SQLite)
- 320 unit tests + 28 integration tests (vitest)
- CI/CD: lint + typecheck + tests (Node 20/22), Docker multi-arch, npm publish
- Go source code removed (47K lines deleted)
Migration report: See reports/2026-03-26-001-typescript-migration-plan.md
Previously Completed¶
| Phase | Description | Status |
|---|---|---|
| Go v1.x–v2.32 | ADT client, 40+ tools, CRUD, debugging, WebSocket, Lua scripting | ✅ Complete (Go) |
| Enterprise Rename | vsp → ARC-1, 11 intent-based tools | ✅ Complete |
| Auth Phase 1: API Key | ARC1_API_KEY Bearer token |
✅ Complete |
| Auth Phase 2: OAuth/OIDC | Entra ID JWT validation via jose library |
✅ Complete |
| Auth Phase 4: BTP CF | Docker on CF with Destination Service + Cloud Connector | ✅ Complete |
| TypeScript Migration | Full Go → TypeScript port, Go code removed | ✅ Complete (2026-03-26) |
| CI/CD Pipeline | GitHub Actions: lint, typecheck, tests (Node 20/22), Docker, npm publish | ✅ Complete |
| Copilot Studio E2E | OAuth + MCP + BTP Destination + Cloud Connector → SAP data | ✅ Complete |
| XSUAA OAuth Proxy | SEC-07: MCP SDK auth + @sap/xssec, Express 5, 3 auth modes coexist | ✅ Complete (2026-03-27) |
| Scope Enforcement | SEC-06: Per-tool scope checks, ListTools filtering, 12 tests | ✅ Complete (2026-03-27) |
| Audit Logging | SEC-04: Multi-sink audit (stderr, file, BTP Audit Log Service) | ✅ Complete (2026-04-01) |
| Dynamic Client Registration | RFC 7591 /register endpoint for MCP clients | ✅ Complete (2026-03-27) |
| Principal Propagation | SEC-01+SEC-02: Per-user ADT client via BTP Dest Service + Cloud Connector | ✅ Code complete (2026-03-27) |
| Hyperfocused Mode | Single SAP tool (~200 tokens) — competitive parity with VSP |
✅ Complete (2026-04-01) |
| Method-Level Surgery | edit_method, list_methods, get_method — 95% token reduction |
✅ Complete (2026-04-01) |
| Runtime Diagnostics | SAPDiagnose — short dumps (ST22), ABAP profiler traces | ✅ Complete (2026-04-01) |
| DDIC Completeness | FEAT-04: DOMA, DTEL, STRU, DDLX, TRAN, BOR, T100, variants | ✅ Complete (2026-04-01) |
| RAP CRUD | DDLS/DDLX/BDEF/SRVD write, SRVB read, batch activation | ✅ Complete (2026-04-01) |
| Context Compression | SAPContext with AST-based dependency extraction (7-30x reduction) | ✅ Complete (2026-04-01) |
| MCP Elicitation | Interactive confirmations for destructive operations | ✅ Complete (2026-04-01) |
| BTP ABAP Environment | OAuth 2.0 browser login, direct BTP connectivity | ✅ Complete (2026-04-01) |
This roadmap is a living document. Priorities may shift based on community feedback and enterprise requirements.