상태: 실험적. 운영 시스템에 사용할 때는 주의하세요.

ABAP ADT MCP 서버

AI 에이전트에게 ADT(ABAP Development Tools)를 통해 SAP ABAP 시스템에 대한 전체 읽기/쓰기 액세스를 제공하는 MCP 서버로, SPNEGO/Kerberos SSO(단일 로그온), X.509 클라이언트 인증서 또는 OAuth 2.0 베어러 토큰으로 인증합니다 — 구성 어디에도 비밀번호가 없습니다. 사용자 이름과 비밀번호는 여전히 폴백으로 사용할 수 있지만 권장되지 않습니다!

abap-adt-api를 래핑하고 ADT 자체가 할 수 없는 한 가지를 추가합니다: RFC 지원 함수 모듈 호출 — SAP Gateway JSON-RPC 2.0 서비스를 통해.

128개 도구 — 객체 CRUD, 소스 편집, 잠금, 트랜스포트, 활성화, 구문 검사, 코드 완성, ABAP Unit, ATC, DDIC, abapGit, 리팩토링, 트레이스, 디버거, RFC 호출.

클라이언트가 실제로 보는 수는 두 배로 줄어듭니다. 프로필(ABAP_MCP_PROFILE)은 표면을 컨텍스트로 교환합니다: core는 9개 도구를 나열하고 all은 129개를 나열하는데, 이는 요청 시 도구 스키마를 가져올 수 없는 클라이언트의 경우 매 턴마다 약 2,700토큰 대 약 17,800토큰입니다. 그리고 서버는 무엇이든 나열하기 전에 시스템이 무엇을 지원하는지 묻습니다, 따라서 abapGit 플러그인이 없는 릴리스에는 400으로 응답할 10개 도구가 제공되지 않습니다. DEV에서는 116개가 남습니다.

이는 mario-andreschak의 mcp-abap-abap-adt-api의 SSO 포크입니다. 주요 차이점: Basic Auth 대신 Kerberos SSO, JSON-RPC/RFC 도구, 도구 정의에서 파생된 라우터, 문서화된 도구 참조.

문서

Related MCP server: ABAP-ADT-API MCP-Server

기능

• 두 가지 비밀번호 없는 로그온 모드 — 로그온한 Windows 사용자의 티켓을 사용한 SPNEGO/Kerberos, 또는 Kerberos ID가 없는 서비스 또는 기술 사용자를 위한 X.509 클라이언트 인증서. 어느 쪽도 SAP 비밀번호를 저장하거나 전송하지 않으며, 세션이 만료되면 둘 다 자가 치유됩니다.

• 이름으로 모든 객체 읽기 — readAbapObject는 한 번의 호출로 이름을 소스로 해석합니다. ADT URL을 찾거나 직접 만들 필요가 없습니다.

• 테이블 설명 — describeAbapTable은 필드, DDIC 유형, 키 플래그 및 체크 테이블을 반환합니다.

• 객체 관리 — ABAP 객체 검색, 읽기, 생성, 수정, 삭제 및 활성화.

• 명명 규칙 조사 — searchPackages는 패턴(["ZPP_*","Z_PP*"])으로 패키지를 찾고 각 패키지를 유형별로 그룹화된 객체로 한 번의 호출로 확장합니다.

• 소스 워크플로 — 잠금 → 편집 → 구문 검사 → 활성화 → 잠금 해제, 트랜스포트 처리 포함.

• 코드 인텔리전스 — 완성, 정의, 사용 참조, ABAP Doc, 프리티 프린터, ATC, ABAP Unit, 리팩토링(이름 변경, 메서드 추출).

• RFC 함수 모듈 호출 — callFunctionViaJsonRpc는 RFC 지원 함수 모듈을 실행하고 시스템에서 읽은 실제 시그니처에 대해 요청을 검증합니다.

• 하나의 LUW에서 배치 RFC 호출 — callFunctionsViaJsonRpc는 여러 함수 모듈을 단일 요청으로 보내며, 이는 업데이트 BAPI와 해당 BAPI_TRANSACTION_COMMIT가 하나의 LUW를 공유할 수 있게 하는 것입니다.

• 데이터 액세스 — tableContents 및 임시 runQuery SELECT.

• 실행 중인 시스템 보기 — listLoggedOnUsers는 TH_USER_LIST에서 "누가 로그온했는지"에 답합니다. SM04 뒤의 데이터입니다. readProfileParameters는 한 번의 왕복으로 RZ11 값을 읽고, checkLogonConfiguration은 시스템이 실제로 수락하는 인증을 알려줍니다.

• 번들 에이전트 스킬 — skills/ 아래 54개 스킬, ABAP(Clean ABAP, RAP, CDS, ATC, abapGit…) 및 일반 엔지니어링(TDD, 코드 리뷰, 버그 진단)용, 리소스로 제공되고 readSkill을 통해 제공됩니다.

• 자체 문서화 — 아래 가이드는 서버 자체에서 MCP 리소스(abap-adt://guides/…) 및 readServerGuide 도구를 통해 제공되므로, 에이전트는 세션을 떠나지 않고 작업 중에 워크플로나 인수를 조회할 수 있습니다.

사전 요구 사항

• ADT를 통해 접근 가능한 SAP ABAP 시스템. /sap/bc/adt가 SICF에서 활성화되어 있어야 합니다. RFC 도구의 경우 /sap/gw/jsonrpc도 활성화되어 있어야 하며(SAP_GWFND), 사용자에게 호출할 함수 그룹에 대한 S_RFC가 필요합니다.

• 비밀번호 없이 로그온하는 방법, 다음 중 하나:

  • 작동하는 Kerberos 로그인 — SAP 시스템이 SPNEGO를 수락해야 하고 유효한 티켓(klist)을 보유해야 합니다. 이것이 기본값이며, 배포된 대로 Windows가 필요합니다: 부트스트랩은 C:\Windows\System32\curl.exe --negotiate를 셸 아웃하는데, 이는 curl의 Schannel/SSPI 백엔드가 필요합니다. 다른 플랫폼에서는 SSO_CURL_PATH를 GSS-API 지원으로 빌드된 curl로 지정하세요.

  • X.509 클라이언트 인증서 — Kerberos ID가 없는 서비스 또는 기술 사용자용. curl도 Windows도 필요 없습니다. SAP가 이를 위해 설정되어야 합니다: ICM 포트가 인증서를 요청해야 하고(icm/server_port_<n>의 VCLIENT, icm/HTTPS/verify_client를 재정의함), 발급 CA가 STRUST에서 신뢰되어야 하며, 사용자에 대한 CERTRULE 매핑이 있어야 합니다. 이 서버에서 이를 확인하는 방법을 포함한 전체 설정은 docs/Authentication.md에 있습니다.

  • OAuth 2.0 클라이언트 — Kerberos 영역도 ICM 구성도 없는 SAP BTP ABAP 환경용, 또는 SOAUTH2를 통해 ADT를 게시하는 온프레미스 시스템용. BTP 서비스 키는 이미 이 중 하나입니다. §11 참조.

• Node.js(LTS) 및 npm — node -v 및 npm -v로 확인하세요.

설치

git clone --recurse-submodules https://github.com/Ciltress/sap-abap-mcp.git
cd sap-abap-mcp
npm install
npm run build

--recurse-submodules가 중요합니다: 일반 엔지니어링 스킬은 서브모듈에 있으며, 이 옵션이 없으면 해당 디렉토리가 비어 있고 서버가 35개 더 적은 스킬을 제공합니다. 이미 클론하셨나요? git submodule update --init --recursive를 실행하세요.

npm의 npx mcp-abap-abap-adt-api 패키지는 업스트림 서버이며 SSO 부트스트랩이나 RFC 도구를 포함하지 않습니다. 대신 이 저장소를 소스에서 빌드하세요.

구성

.env.example을 .env로 복사하고 시스템 정보를 입력하세요:

SAP_URL=https://your-sap-server.example.com:44301
SAP_USER=YOUR_SAP_USER
SAP_CLIENT=100
SAP_LANGUAGE=EN

SAP_URL과 SAP_USER는 필수입니다. SAP_CLIENT와 SAP_LANGUAGE는 선택 사항이지만 권장됩니다. 네 가지 로그온 모드 중 세 가지는 SAP_PASSWORD가 전혀 필요 없습니다.

.env를 커밋하지 마세요. 이미 .gitignore에 있습니다.

클라이언트에 맞게 서버 크기 조정

세 가지 ABAP_MCP_* 변수는 한 가지 이유로 존재합니다: 요청 시 도구 스키마를 가져올 수 없는 클라이언트는 매 턴마다 전체 도구 목록에 대한 비용을 지불합니다. Claude Code는 스키마를 지연시키므로 기본값을 유지해야 합니다. 128k 창의 8B 모델은 대화가 시작되기 전에 컨텍스트의 6분의 1을 소비하며, "동일한 프롬프트가 절반의 시간만 작동하는" 이유가 바로 여기입니다.

ABAP_MCP_PROFILE — 설정하지 않으면 all을 의미하므로 기존 설정은 변경되지 않습니다.

개수에는 healthcheck가 포함됩니다. healthcheck는 모든 프로필 밖에 있는데, "지금 실행 중인 프로필이 무엇인가?"에 답하는 도구이기 때문입니다.

프로필은 편의 필터가 아닙니다. 활성 프로필 밖의 도구는 목록에 표시되지 않고 라우팅되지도 않으므로 호출할 수 없습니다. 이것이 analyst가 더 작은 메뉴가 아니라 소스를 편집하는 일이 없음을 보장하는 이유입니다. 프로필 밖 호출은 "알 수 없는 도구" 대신 그 이유를 알려주는 오류를 받으므로 재시도할 필요가 없습니다. 인식할 수 없는 프로필 이름은 all로 폴백하는 대신 시작 시 서버를 중지시킵니다. 9개를 요청한 대상에 129개 도구를 조용히 제공하는 것은 프로필이 존재하는 이유인 바로 그 실패이기 때문입니다.

core가 작은 이유는 editAbapSource 하나가 쓰기 주기 그 자체이기 때문입니다. 잠금, 쓰기, 활성화, 잠금 해제를 수행하며 단계가 실패해도 잠금을 해제합니다. 네 개의 개별 단계는 dev와 all에 남아 있습니다.

ABAP_MCP_MAX_RESPONSE_BYTES — 도구 목록은 프로필이 줄일 수 있는 고정 비용이고, 응답은 상한이 없습니다. core에서 전체 도구 목록은 ~11KB인 반면 adtDiscovery 하나는 ~42KB입니다. 설정하지 않으면 프로필을 따릅니다(core 24,000바이트, analyst 32,000, dev 48,000, all 상한 없음). 0이면 제한을 제거합니다.

예산을 초과하는 응답은 보류되고 유효한 JSON으로 대체됩니다 — status:"truncated", 원래 bytes, budget, 2,000바이트 preview, nextStep — 잘린 조각으로 대체되지 않습니다. 잘린 조각은 파싱되지 않고 동일한 재시도를 유발할 뿐이기 때문입니다.

ABAP_MCP_GATE — 서버는 무엇이든 나열하기 전에 시스템에 지원하는 것을 묻고, ADT 컬렉션이 없는 도구는 제외합니다. DEV에서는 abapGit 도구 10개와 service-binding 도구 3개가 해당되며, 그렇지 않으면 HTTP 400으로 응답할 것입니다. 프로세스당 discovery 왕복 한 번이 들고, 목록을 줄일 수만 있으며, 어떤 실패가 있어도 모든 도구가 나열된 상태로 남습니다. ABAP_MCP_GATE=off면 이 과정을 건너뜁니다.

healthcheck는 세 가지를 모두 보고합니다. 활성 프로필, responseBudgetBytes, 그리고 제외된 항목입니다.

Kerberos 대신 인증서

서비스 또는 기술 사용자의 경우 인증서를 추가하세요. 그것만으로 모드가 전환됩니다:

SAP_USER=CLAUDEAGENT                                 # the user CERTRULE maps the certificate to
SAP_CERT_FILE=C:\Users\svc_agent\SNC\sec\claudeagent.p12
SAP_CERT_PASSPHRASE=<PKCS#12 password / PSE PIN>

이것은 상호 TLS이지 SNC가 아닙니다 — ADT는 HTTPS입니다. RFC/SNC에서 이미 작동하는 인증서는 재사용할 수 있고 그 CERTRULE 매핑도 그대로 적용되지만, SNC0 ACL은 역할을 하지 않으며 ICM에는 icm/HTTPS/verify_client가 필요합니다. docs/Authentication.md에서 차이점, sapgenpse export_p12 / OpenSSL 3 함정, 그리고 거부된 인증서를 읽는 방법을 다룹니다.

BTP 및 SOAUTH2용 OAuth 2.0 클라이언트

SAP BTP ABAP 환경이나 인증 서버 뒤에서 ADT를 제공하는 온프레미스 시스템의 경우입니다. 클라이언트 ID를 설정하면 모드가 전환됩니다:

SAP_OAUTH_TOKEN_URL=https://your-tenant.authentication.eu10.hana.ondemand.com/oauth/token
SAP_OAUTH_CLIENT_ID=sb-abap-agent!t1234              # 'clientid' in a BTP service key
SAP_OAUTH_CLIENT_SECRET=<'clientsecret'>

온프레미스에서 엔드포인트는 SAP 호스트 자체에 있습니다 — https://<host>:<port>/sap/bc/sec/oauth2/token — 그리고 클라이언트는 SOAUTH2에 등록된 것입니다.

토큰은 한 번만 로그온합니다. 그 후에는 다른 모드와 마찬가지로 SAP 세션 쿠키가 모든 요청을 운반합니다. 따라서 5분 후에 만료되는 토큰도 문제가 되지 않습니다. AS ABAP의 OAuth 2.0 클라이언트는 SU01의 사용자 이기도 합니다. 잘못된 SAP_OAUTH_CLIENT_SECRET은 비밀번호처럼 login/fails_to_user_lock에 집계되므로, 거부된 토큰 요청은 절대 재시도되지 않습니다. authorization-code 흐름은 구현되어 있지 않습니다. 브라우저가 필요한데, stdio로 시작된 서버는 브라우저를 열 방법이 없기 때문입니다. 한 번은 직접 완료하고 리프레시 토큰을 전달하세요. docs/Authentication.md §11에 어떤 실패가 고정되는지와 그 이유를 포함한 자세한 내용이 있습니다.

다른 방법이 없을 때의 비밀번호

Kerberos도 인증서도 없는 시스템 — 샌드박스, 트라이얼, 도메인 밖의 모든 것 — 의 경우입니다:

SAP_USER=CLAUDEAGENT
SAP_PASSWORD=<the password>

최후의 수단이며, 다른 두 가지와 대체할 수 없습니다. 티켓이 없거나 매핑되지 않은 인증서는 그냥 거부됩니다. 그러나 잘못된 비밀번호는 login/fails_to_user_lock에 집계되어 이 서버뿐만 아니라 그 사용자를 사용하는 모든 소비자에 대해 해당 사용자를 잠급니다. 구현은 이런 이유로 거부된 비밀번호 재시도를 거부합니다. 실패한 로그온 하나가 고정되면, 도구를 몇 개 호출하든 상관없습니다. 무인 작업에는 인증서를 선호하세요. docs/Authentication.md §10에 자세한 내용이 있습니다.

MCP 클라이언트에 등록

클라이언트가 빌드된 엔트리 포인트를 절대 경로로 가리키게 하세요:

{
  "mcpServers": {
    "sap-abap-dev-100": {
      "command": "node",
      "args": ["C:/path/to/sap-abap-mcp/dist/index.js"],
      "env": {
        "SAP_URL": "https://your-sap-server.example.com:44301",
        "SAP_USER": "YOUR_SAP_USER",
        "SAP_SYSTEM_ID": "DEV",
        "SAP_CLIENT": "100",
        "SAP_LANGUAGE": "EN"
      }
    }
  }
}

클라이언트의 env 블록이 .env보다 우선합니다. npm run start를 실행하면 서버를 직접 시작하고, npm run dev를 실행하면 MCP Inspector를 통해 서버를 구동합니다.

매 턴마다 모든 도구 스키마를 전달하는 클라이언트라면 같은 블록에 프로필을 추가하세요:

"env": { "…": "…", "ABAP_MCP_PROFILE": "core" }

Docker에서

서버는 stdio를 통해 MCP를 사용하므로 공개할 포트가 없습니다. 클라이언트가 컨테이너를 시작하고 stdin/stdout으로 통신합니다.

docker build -t abap-adt-mcp .

{
  "mcpServers": {
    "sap-abap-dev-100": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "--env-file", "C:/path/to/.env", "abap-adt-mcp"]
    }
  }
}

네 가지 로그온 모드 모두 여기서 작동합니다. 그러나 자격 증명은 컨테이너에 주어져야 하는 것이며, --env-file은 dotenv가 아닙니다. Docker는 따옴표를 제거하지 않고, export를 읽지 않으며, 끝의 # comment를 버리지 않으므로 dotenv라면 정리했을 값이 그대로 전달됩니다. .env의 Windows 경로는 마운트된 경로로 바꿔야 합니다. Kerberos는 컨테이너에서 가장 많은 것을 요구하는 모드이고 OAuth는 가장 적게 요구합니다. 토큰은 네트워크를 통해 가져오므로 아무것도 마운트할 필요가 없습니다.

인증서 모드 — 키 자료를 읽기 전용으로 마운트하고, SAP 인증서를 서명한 CA도 함께 마운트하세요:

docker run -i --rm --env-file .env \
  -v /host/certs:/certs:ro \
  -e SAP_CERT_FILE=/certs/agent.p12 \
  -e SAP_CA_FILE=/certs/corporate-root.pem \
  abap-adt-mcp

Kerberos 모드 — 이미지에는 GSS-API와 kinit에 대해 빌드된 curl이 포함되어 있으므로 남은 것은 realm과 자격 증명입니다:

docker run -i --rm --env-file .env \
  -v /etc/krb5.conf:/etc/krb5.conf:ro \
  -v /host/agent.keytab:/krb5/agent.keytab:ro \
  -e SAP_KRB_KEYTAB=/krb5/agent.keytab \
  -e SAP_KRB_PRINCIPAL=SVC_AGENT@CORP.EXAMPLE.COM \
  abap-adt-mcp

OAuth 2.0 모드 — 마운트할 것이 없습니다. 자격 증명은 가져옵니다:

docker run -i --rm --env-file .env \
  -e SAP_OAUTH_TOKEN_URL=https://your-tenant.authentication.eu10.hana.ondemand.com/oauth/token \
  -e SAP_OAUTH_CLIENT_ID='sb-abap-agent!t1234' \
  -e SAP_OAUTH_CLIENT_SECRET=<clientsecret> \
  abap-adt-mcp

비밀번호 모드 — 최후의 수단!

docker run -i --rm --env-file .env \
  -e SAP_USER=YourUser \
  -e SAP_PASSWORD=YourPassword \ 
  abap-adt-mcp

그것을 사용하기 전에 알아야 할 세 가지:

• 키탭이지 여러분의 티켓이 아닙니다. 컨테이너는 대화형 로그온처럼 세션의 자격 증명을 빌릴 수 없습니다. Linux 호스트에서는 이미 가지고 있는 티켓 캐시를 마운트할 수 있지만(-v /tmp/krb5cc_1000:/krb5/ccache:ro -e KRB5CCNAME=FILE:/krb5/ccache), 호스트의 캐시와 함께 만료됩니다. Windows 호스트에서는 둘 다 작동하지 않습니다: TGT는 LSA 캐시에 있으며 파일로 쓸 수 없습니다. 이 중 아무것도 필요 없는 인증서 모드를 사용하세요. 키탭은 무인으로 실행되는 유일한 자격 증명이자 티켓 수명보다 오래 지속되는 유일한 자격 증명입니다.

• SAP의 인증서를 검증하거나, 검증하지 않고 있다는 사실을 알아야 합니다. 이미지는 공용 CA 번들만 신뢰하므로 호스트가 신뢰하는 내부 CA는 여기서 알 수 없고 핸드셰이크가 UNABLE_TO_GET_ISSUER_CERT_LOCALLY로 실패합니다. 루트 CA를 마운트하고 SAP_CA_FILE이 그것을 가리키게 하세요. 데스크톱 .env를 통째로 가져오면 대신 이것이 숨겨집니다. NODE_TLS_REJECT_UNAUTHORIZED=0은 개발용 설정이며 배포된 이미지에 있을 자격이 없습니다.

• --recurse-submodules 클론에서 빌드하세요. skills/Development는 서브모듈입니다. 그것 없이 이미지는 스킬이 35개 적게 포함됩니다.

이미지가 Alpine 대신 Debian인 이유는 하나입니다. Alpine의 curl은 GSS-API 없이 빌드되었고, 그런 curl은 실패하지 않습니다. 그저 토큰을 절대 보내지 않으며, SAP는 만료된 티켓이 만들어내는 것과 같은 401로 응답합니다. 무엇이 빠졌는지는 세션을 시도하기 전에 시작 시 stderr로 알려줍니다. 컨테이너가 최종적으로 어떤 자격 증명을 사용했는지 묻으려면 서버 대신 명령을 주세요:

docker run --rm --env-file .env -v /host/agent.keytab:/krb5/agent.keytab:ro \
  -e SAP_KRB_KEYTAB=/krb5/agent.keytab abap-adt-mcp klist

docs/, skills/ 및 AGENTS.md는 의도적으로 이미지에 복사됩니다. 서버는 런타임에 이들을 읽어 readServerGuide, readSkill 및 abap-adt:// 리소스를 제공합니다. docs/Authentication.md §7에 모드별 전체 컨테이너 설정이 있습니다.

시스템이 여러 개인 경우

서버는 수명 전체에 걸쳐 하나의 시스템과 하나의 클라이언트에 바인딩됩니다. 둘 다 런타임에 전환할 수 없습니다. 따라서 시스템/클라이언트마다 엔트리 하나를 등록하고 각각에 SAP_SYSTEM_ID를 지정하세요:

"sap-abap-dev-100": { "env": { "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "100", "…": "…" } },
"sap-abap-dev-200": { "env": { "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "200", "…": "…" } },
"sap-abap-q01-100": { "env": { "SAP_SYSTEM_ID": "Q01", "SAP_CLIENT": "100", "…": "…" } }

그러면 각 서버는 연결 시 반환하는 MCP instructions에서 자신을 알립니다:

이 서버는 SAP 시스템 DEV, 클라이언트 100에 바인딩되어 있습니다 (https://…:44301). 런타임에 시스템이나 클라이언트를 전환할 수 없습니다. 둘 다 시작할 때의 환경에 의해 고정됩니다. 요청이 다른 시스템이나 클라이언트를 지정하면 그에 맞게 구성된 MCP 서버를 사용하세요. 등록된 것이 없으면 여기서 처리하지 말고 그렇게 말하세요.

그래야 에이전트가 "DEV 클라이언트 200에서 이것을 확인해 주세요"라는 요청을 아무것도 호출하지 않고 올바른 서버로 라우팅할 수 있습니다. healthcheck는 직접 물어봐야 하는 서버에 대해 동일한 신원을 보고합니다.

선언은 검증됩니다. SAP는 로그온 시 설정하는 세션 쿠키(SAP_SESSIONID_DEV_100)에 시스템과 클라이언트를 명시하므로 서버는 실제로 연결된 대상을 압니다. 그것이 SAP_SYSTEM_ID와 일치하지 않으면 — 예를 들어 잘못된 호스트를 가리키는 복사-붙여넣기 엔트리 — healthcheck는 WARNING을 포함하고 시작 시 크게 로그로 남깁니다. 주의할 가치가 있습니다. 모든 도구가 완벽하게 계속 작동하기 때문입니다. 다만 잘못된 시스템에서 말이죠.

빠른 둘러보기

이름으로 아무 객체나 읽으세요. URL discovery가 필요 없습니다:

{"tool":"readAbapObject","args":{"objectName":"ZCL_MY_CLASS"}}
{"tool":"describeAbapTable","args":{"tableName":"T000"}}

전체 명명 규칙을 조사하세요. 패턴이 자동으로 정규화되므로 zpp_lab은 ZPP_LAB*이 됩니다:

{"tool":"searchPackages","args":{"patterns":["ZPP_*","Z_PP*"]}}
// -> each package with its objects grouped by type, sub-packages, and a `truncated` flag

함수 모듈을 호출하세요. 시그니처를 먼저 읽고 요청을 그에 대해 검증합니다:

{"tool":"readAbapFunctionModule","args":{"functionModuleName":"STFC_CONNECTION"}}
{"tool":"callFunctionViaJsonRpc","args":{"functionModuleName":"STFC_CONNECTION",
                                         "inputParameters":{"REQUTEXT":"hello"}}}

BAPI와 그 커밋은 하나의 배치로 이동해야 합니다. 그렇지 않으면 커밋이 자체 LUW에 들어가고 BAPI의 변경 사항이 손실됩니다:

{"tool":"callFunctionsViaJsonRpc","args":{"calls":[
  {"functionModuleName":"BAPI_USER_LOCK","inputParameters":{"USERNAME":"DEVUSER"}},
  {"functionModuleName":"BAPI_TRANSACTION_COMMIT","inputParameters":{"WAIT":"X"}}
]}}

전체 쓰기 주기(lock → modify → check → activate → unlock), 디버거, ATC 및 기타 모든 워크플로는 docs/MCP-Tools.md §4에 있습니다.

ABAP 객체 다루기

세 가지 도구가 필요한 대부분을 다루며, 각각은 ADT URL이 아니라 이름을 받습니다:

{"tool":"readAbapObject",   "args":{"objectName":"ZCL_MY_CLASS"}}
{"tool":"describeAbapTable","args":{"tableName":"T000"}}
{"tool":"searchPackages",   "args":{"patterns":["ZPP_*","Z_PP*"]}}

readAbapObject는 메타데이터 그리고 소스를 요청한 번의 호출로 반환합니다. 하나의 이름이 여러 객체에 속할 때 — ZPP_EXT_LABEL_DATA는 함수 그룹이자 함수 모듈 — 더 구체적인 것을 선택하고 ambiguous:true 및 alternatives로 알려줍니다. objectType을 전달하여 선택을 강제할 수 있습니다. 소스가 없는 객체는 hasSource:false와 함께 그리고 올바른 도구를 가리키는 포인터와 함께 반환됩니다.

describeAbapTable은 필드 이름, DDIC 유형, 길이, 키 플래그, 데이터 요소, 도메인 및 check tables를 제공합니다. check table는 외래 키 대상이며, 두 테이블이 어떻게 조인되는지 보여줄 수 있는 가장 빠른 방법입니다. objectStructure는 테이블에 필드를 반환하지 않으며, tableContents는 정의가 아니라 행을 반환함으로써 "이 테이블은 과연 어떻게 보일까"라는 질문에 응답하지 않습니다.

클라이언트 시스템 프롬프트에 포함할 규칙

• 이름 기준 도구를 사용하세요. 중간 결과가 필요할 때만 searchObject → objectStructure → getObjectSource로 대체하세요. /sap/bc/adt/... 경로를 직접 만들지 마세요.

• 효율적으로 선택하세요. SAP 테이블은 대용량입니다. SELECT는 항상 WHERE 절로 제한하고, 사용할 수 없으면 SELECT SINGLE(전체 키 필드를 알고 있을 때) 또는 UP TO n ROWS를 사용합니다.

SELECT vgbel FROM vbrp WHERE vbeln = @lv_vbeln INTO @DATA(lv_vgbel) UP TO 1 ROWS.
  EXIT.
ENDSELECT.

SAP는 파일시스템과 분리되어 있습니다. 소스 코드를 읽으면 도구 결과로만 제공되며, 로컬 파일에 읽어도 SAP에서는 변경되는 것이 없습니다. 로컬 사본은 diff 용도로만 유용합니다.

이전 README에는 GetTable, GetStructure, GetTypeInfo 등이 있었습니다. 이는 별도의 mcp-abap-adt 프로젝트에 속한 것으로, 이 서버에는 해당하지 않습니다.

개발

npm run build          # tsc -> dist/
npm test               # jest: parser, tool catalogue, JSON-RPC handler (no SAP system needed)
npx tsc --noEmit       # type check only

테스트는 src/__tests__ 안에 있으며 완전히 오프라인으로 실행됩니다. JSON-RPC 스위트는 Fake 가짜 SAP Gateway 노드를 처리기를 엔드투엔드로 검증합니다.

대규모 actual실제 시스템(카베르로스 티켓 필요)에서 편대편 확인 절차:

npm run build
node scripts/live-jsonrpc-check.mjs      # add NODE_TLS_REJECT_UNAUTHORIZED=0 for an internal CA

사람이 브라우저처럼 MCP stdio로 빌드 서버를 구동시키며 읽기 전용 함수 모듈만 호출합니다.

도구를 추가하는 것은 한 파일 변경으로 결정됩니다 — docs/MCP-Tools.md §10을 참조하세요.

문제 해결

더 자세한것은 docs/MCP-Tools.md §8 참조.

기여 방법

1. 리포지토리 №11을 포크하세요.

2. git checkout -b feature/your-feature-name

3. 변경사항을 구현하고 npm test 및 npx tsc --noEmit가 성공 통과이.(이 유지하세요)

4. git commit -m "Add some feature" 및 git push origin feature/your-feature-name

5. Pull request를 열기

라이센스

MIT. 업스트림 프로젝트 및 기여 원저자: mario-andreschak

This contains many errors. Let's not produce broken text. Instead, need a clean final.

Let's carefully compose final now in human language, no slang.

We'll use: