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., "@RCP-1 show me the ABAP code for program ZMYPROG"
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.
RCP-1 — 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.
RCP-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.
Built for organizations that need AI-assisted SAP development with guardrails — RCP-1 provides what's needed to run in production:
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) — SAPRead(type=TABLE_CONTENTS) and SAPQuery are gated behind explicit env vars (SAP_ALLOW_DATA_PREVIEW=true, SAP_ALLOW_FREE_SQL=true). These capabilities can expose application data or run ad-hoc SQL, so they are intentionally separated from the default development-tooling surface. They can be enabled for governed use cases, but should be reviewed against the current SAP API Policy, your SAP agreement, and internal data-governance rules
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 — RCP1_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 RCP1_MCP_HTTP_RATE_LIMIT overrides it), per-user MCP quota (Layer 2, off by default — multi-user deployments opt in via RCP1_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
Supply-chain security — Dependabot (npm + GitHub Actions + Docker, weekly + same-day security advisories), npm audit --audit-level=high PR gate, GitHub Dependency Review on every PR, CodeQL SAST, Trivy container scanning (gating on release, advisory on dev), all third-party GitHub Actions pinned to commit SHA, SECURITY.md policy with severity-tiered SLAs. Image and npm package both ship with provenance attestations, and the release workflow publishes a best-effort CycloneDX SBOM for the production npm dependency graph. See the security guide §13
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
Deploy RCP-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, mutation-free BTP mode discovers
destinations marked rcp1.enabled=true and exposes pinned SID/client plus aggregate endpoints
(setup,
administration)
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, RCP-1 handles the BTP token exchange
Audit logging — structured events to stderr, file, or BTP Audit Log Service
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)
Context-first understanding — SAPContext(action="deps") is the first call for "what does this object do?": it returns the object's Knowledge Transfer Document (SKTD/KTD) when available plus public API contracts of dependencies in one call (7-30x compression)
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 graph caching — SAPContext dep resolution keyed by source hash; unchanged objects skip all ADT calls on subsequent runs.
KTD-aware context — Knowledge Transfer Documents are cached as source entries and composed into SAPContext(action="deps") separately from the dependency graph, so cached dependency context can still include revalidated documentation.
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 for full documentation.
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 RCP-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)
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 ( |
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 ( |
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 | Execute ABAP SQL with table-not-found suggestions and automatic chunking for simple long literal |
SAPTransport | CTS transport management (list/get/create/release/delete/reassign/release-recursive), transport layer/target lookup, package transport requirement checks, and reverse lookup history ( |
SAPGit | Git-based ABAP workflows across gCTS and abapGit (list/clone/pull/push/commit/branch/unlink) with backend auto-selection and safety gating ( |
SAPContext | Context-first object understanding ( |
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 ( |
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.
RCP-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
Related MCP server: dassian-adt
SAP's current SAP API Policy is v.4.2026a. It allows published/documented APIs for the purposes described in SAP documentation, while restricting unsupported internal APIs, misuse, unmanaged autonomous AI call patterns, and large-scale extraction outside endorsed paths. RCP-1 is designed as a governed development-tooling proxy around ADT behavior, not as a bulk data-extraction product.
For typical internal developer workflows, RCP-1 should be treated as generally usable when it stays close to documented/discoverable ADT behavior, runs with real user identity, respects SAP authorization, and keeps audit and rate controls in place. Customers should still review their exact landscape, SAP agreement, and AI governance rules, especially when the MCP client can plan or execute sequences of tool calls.
Concretely, RCP-1 is positioned as a custom developer utility for internal development automation: code checks, build/activate, transport management, AI-assisted ABAP authoring, and Git workflows.
Two RCP-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 |
Named table content preview ( |
|
| Can expose application-table data; keep off unless the use case is approved. |
Freestyle ABAP SQL ( |
|
| Executes ad-hoc ABAP SQL; keep off unless the use case is approved. |
With both flags at their defaults, RCP-1's data/sql rows are unreachable. Turning either flag on is a valid operational choice for approved scenarios, but it should be deliberate: check the current SAP API Policy, the customer's SAP agreement, SAP authorizations, and internal data-protection rules before enabling it on a productive system.
Beyond the policy, the public signals for ADT remain consistent: SAP publishes an ADT SDK, a guide for creating and consuming RESTful APIs in ADT, and has described the ABAP language server direction as an "ADT SDK 2.0".
RCP-1's strategy is to stay close to documented and discoverable ADT behavior, probe system capabilities before exposing tools, keep conservative security defaults (writes off, data preview off, free SQL off, package allowlist $TMP), and continuously review SAP's guidance as it evolves. This README is not a compliance decision for any specific customer landscape, but the default posture is intended to support normal governed development use rather than block it.
Install in Claude — pick your surface (full guide: Install in Claude):
Claude Desktop — download the latest rcp-1-*.mcpb from Releases and double-click it (or Settings → Extensions). Claude prompts for your SAP connection. (The .mcpb is 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 dhruvmahendrapatel/abap-mcp-rcp-v1
/plugin install rcp-1@rcp-1Any MCP client / manual — run it directly:
npx rcp-1@latest --url https://your-sap-host:44300 --user YOUR_USERTrying it out on your laptop? → Quickstart
Full local dev setup (Docker, cookie extractor, client configs)? → Local Development
Deploying for a team / BTP? → Deployment
Full documentation is available at github.com/dhruvmahendrapatel/abap-mcp-rcp-v1.
Guide | Description |
5-minute npx + Claude Desktop setup | |
Desktop | |
Full local dev — all install methods, MCP client configs, SSO cookie extractor | |
Multi-user deployment — Docker, BTP Cloud Foundry, BTP ABAP | |
Choose the BTP topology and follow the correct deployment, auth, destination, and operations guides | |
MTA deployment, topology decision, role handoffs, and safe acceptance | |
Changes, roles, secrets, scaling, upgrades, rollback, and customer handover | |
Experimental read-only BTP multi-target deployment, destinations, roles, and client configuration | |
Every flag and env var, one table | |
Update procedures per install method | |
Layer A / Layer B auth internals, coexistence matrix | |
Complete reference for all 12 tools | |
Add your own | |
System architecture with diagrams | |
Agent workflow patterns and best practices | |
Reusable RCP-1 agent skills, including GitHub Copilot in Eclipse and VS Code ADT setup |
npm ci && npm run build && npm testSee CLAUDE.md for codebase structure, testing commands, and contribution guidelines.
Project | Author | Contribution |
oisee | Original Go MCP server — RCP-1's starting point | |
Marcello Urbani | TypeScript ADT library, definitive API reference | |
Mario Andreschak | First MCP server for ABAP ADT | |
Lars Hvam | ABAP parser/linter (used via @abaplint/core) |
MIT
Primary tool for understanding ABAP/CDS objects before specs, reviews, explanations, or changes — use instead of SAPRead when the user asks what an object does. Returns intent first (the object KTD when available) then compressed dependency contracts. Use SAPRead after SAPContext for exact source/method bodies/grep/drafts.
Decision rule — pick the action from the user's question:
"What breaks if I change ?" / "Who consumes <I_*>?" / "Blast radius" → action="impact" (DDLS only).
"Which includes/appends extend ?" → action="structure", type="TABL".
"What does do?" / "Explain" / "deps before editing" → action="deps" (default).
"Find all callers of " → action="usages" (live SAP where-used lookup).
impact (CDS blast-radius): upstream AST deps + downstream where-used, classified into RAP buckets (projectionViews, bdefs, serviceDefinitions, serviceBindings, accessControls, metadataExtensions, abapConsumers, documentation, tables, other) + sibling-consistency hints. Use this instead of text-scanning DDDDLSRC/ACMDCLSRC with SAPQuery (it filters the noise). Optional includeIndirect, siblingCheck, siblingMaxCandidates. deps (default): target KTD + the public API contracts of its dependencies (not full source) — one compact response vs N SAPRead calls (7-30x fewer tokens); SAP standard objects filtered out. For CDS, includes dependency DDL/field catalogs for cl_cds_test_environment. structure (TABL only): the DDIC include/append tree.
Use SAPContext BEFORE editing existing objects. For non-CDS reverse-lookup use SAPNavigate(references); for CDS prefer impact. Full detail: docs_page SAPContext.
Inputs: name (required), type, depth, group, +8 more.
Run diagnostics on ABAP objects and analyze runtime errors. Actions:
"syntax": syntax-check (name+type; optional version; optional source = pre-write dry-run, nothing written).
"unittest": run ABAP Unit tests (name+type).
"atc": run ATC checks (name+type; optional variant). "atc_variants": list variants + the system default (variant = name filter; read-only).
"cds_testcases": SAP-suggested ABAP Unit test cases for a CDS entity (name; read-only; SAP_BASIS 8.16+).
"object_state": compare active vs inactive source versions (name+type; CLAS compares all includes). Returns ETags/hashes/divergence flags.
"quickfix": get quick-fix proposals at a position (name+type+source+line; optional column, sourceUri).
"apply_quickfix": apply one proposal, return text deltas, no write (name+type+source+line+proposalUri+proposalUserContent; pass proposalUserContent through exactly).
"dumps": list/read ST22 short dumps (no id = list; id = read; includeFullText, sections).
"traces": list/analyze profiler traces (id+analysis: hitlist=hot spots, statements=call tree, dbAccesses=DB stats).
"trace_start": arm a profiler trace for the NEXT matching execution, then reproduce and read via "traces" (write scope; defaults: next HTTP request, SQL on).
"trace_requests": list armed trace requests. "trace_cancel": cancel one by id (write scope).
"system_messages": list SM02 messages. "gateway_errors": list /IWFND/ERROR_LOG (on-prem; detailUrl or id+errorType for detail).
"odata_perf": diagnose why an OData call is slow (url = host-relative path); returns the sap-statistics timing split (DB/ABAP/framework/auth). Read-only; needs allowDataPreview.
"authorization_trace": read the on-prem STUSERTRACE auth trace (SUAUTHVALTRC); needs SAP_ALLOW_DATA_PREVIEW.
"cds_sql": show the native SQL a CDS view compiles to (name; read-only).
"sql_trace_state" / "set_sql_trace_state" (sqlOn; needs SAP_ALLOW_WRITES) / "sql_trace_directory": ST05 SQL-trace control. Quickfix workflow: syntax/ATC → quickfix → apply_quickfix → write via SAPWrite. Full action reference: docs_page SAPDiagnose.
Inputs: action (required), id, to, url, +31 more.
Run local abaplint rules on ABAP/CDS source (auto-selects cloud or on-prem rules by system type). Actions:
"lint": check source (errors+warnings) for ABAP (PROG/CLAS/INTF/FUNC) and CDS (DDLS).
"lint_and_fix": lint + auto-fix fixable issues (keyword case, obsolete statements); returns fixed source.
"list_rules": list rules + current config (no source).
"format": pretty-print via SAP's ADT formatter (needs source).
"get_formatter_settings" / "set_formatter_settings": read/update the system's global PrettyPrinter (indentation bool, style keywordUpper|keywordLower|keywordAuto|none; set is blocked read-only). lint/lint_and_fix/list_rules run locally; format/*_formatter_settings call SAP. For ATC/syntax/unit tests use SAPDiagnose.
Inputs: action (required), name, rules, style, +2 more.
Probe and report SAP system capabilities. Use BEFORE operations that depend on optional features (abapGit, RAP/CDS, AMDP, HANA, UI5/Fiori, CTS transports, FLP). Also handles package (DEVC) lifecycle.
Actions:
"features": cached feature status (fast, no round-trip; id, available, mode, probedAt). "probe": re-probe now (feature probes + auth + discovery refresh). "cache_stats": object cache health.
"create_package" / "delete_package" / "change_package": DEVC lifecycle via ADT packages API.
FLP read: flp_list_catalogs, flp_list_groups, flp_list_tiles (catalogId). FLP write: flp_create_catalog, flp_create_group, flp_create_tile, flp_add_tile_to_group, flp_delete_catalog.
"set_api_state": release/revoke an object's API release contract (objectUri, or name+objectType; apiState defaults RELEASED, contract defaults C1 — C0 for SRVD, C3 for classic views). Write counterpart of SAPRead(type="API_STATE").
Returns features + systemType ("onprem"/"btp"); "available: false" means do NOT attempt dependent operations.
Inputs: action (required), name, tile, title, +19 more.
Read SAP ABAP objects — exact raw source, a method body, grep output, inactive drafts, revision history, or metadata. For "what does this object do?", explanations, spec work, reviews, or pre-change orientation, prefer SAPContext first (intent-level context before raw source). Types: PROG, CLAS, INTF, FUNC, FUGR (expand_includes=true for all include sources), INCL, DDLS, DCLS, DDLX, BDEF, SRVD, SRVB, SKTD/KTD (KTD aliases SKTD), TABL (covers both transparent tables AND DDIC structures — no separate STRU type), VIEW, DOMA, DTEL, TRAN, TABLE_CONTENTS (single-column filter), TABLE_QUERY (multi-column WHERE via the freestyle endpoint; gated by allowDataPreview; CDS views need SAP_BASIS 752+), DEVC, SOBJ (BOR — method param reads one method), SYSTEM, COMPONENTS, MSAG, TEXT_ELEMENTS, VARIANTS, BSP, BSP_DEPLOY, API_STATE (contract states C0-C4; objectType for non-class), INACTIVE_OBJECTS (no name; pending-activation list), AUTH, FEATURE_TOGGLE, ENHO, VERSIONS, VERSION_SOURCE. AUTH/FEATURE_TOGGLE/ENHO/VERSIONS/VERSION_SOURCE are on-prem only. CLAS: to save tokens, prefer method="*" (all signatures), method="NAME" (one body, ~95% fewer tokens than the full class), or grep over reading the full source. Omit include for the full source, or include=definitions|implementations|macros|testclasses for a local section. Full per-type detail: docs_page SAPRead. Optional grep: case-insensitive regex returning only matching source lines (+context, line numbers); for CLAS, matches are annotated with the owning class/method. Optional version parameter (default "active"): "inactive" reads the user's draft, "auto" the developer view. Active reads note when an inactive draft exists.
Inputs: type (required), to, from, grep, +19 more.
Search for ABAP objects, exact object-directory entries, or source code. Modes:
Object search (default): name pattern with wildcards (*); returns type, name, package, description, ADT URI.
TADIR lookup (searchType="tadir_lookup"): exact cross-package lookup of one or more names (prefer over long SAPQuery TADIR IN-lists). Tips: BOR objects appear as SOBJ; the uri field feeds SAPNavigate, objectType feeds SAPRead/SAPWrite/SAPActivate. Searches object NAMES only — for field names use SAPRead(type='DDLS', include='elements') or SAPQuery on DD03L.
Inputs: names, query, source, maxResults, +3 more.
Manage CTS transport requests (SE09/SE10). Actions: list (current user, modifiable), get (tasks + objects), create (always a Workbench (K) request — the package/target sets target & layer, not the request category; optional explicit target), release, delete, remove_object (keep the request), reassign (change owner), release_recursive (tasks then parent), check (does a package need a transport — type, name, package), history (transports referencing an object — type, name; read-only, no write scope needed). IDs look like A4HK900123. Status: D=modifiable, R=released.
Inputs: action (required), id, name, type, +12 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Scored across 8 tools
Each tool has a clearly distinct purpose: SAPRead for raw source, SAPSearch for object names, SAPNavigate for code navigation, SAPTransport for transport management, SAPLint for static analysis, SAPDiagnose for diagnostics, SAPContext for understanding, and SAPManage for system capabilities. No overlap in functionality.
All tool names follow a consistent 'SAP' prefix plus a descriptive verb/noun (Read, Search, Navigate, Transport, Lint, Diagnose, Context, Manage), maintaining a uniform pattern.
With 8 tools, the set is well-scoped for an SAP ABAP development environment, covering reading, searching, navigation, transport, linting, diagnostics, context analysis, and system management without being overwhelming.
The tools cover analysis and management well, but lack a direct tool for writing or modifying ABAP objects (e.g., SAPWrite). While SAPTransport and SAPManage handle some writes, the absence of code-writing capabilities is a notable gap for a development-oriented server.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
