Статус: экспериментальный. Используйте с осторожностью на продуктивных системах.

ABAP ADT MCP Server

MCP-сервер, который даёт ИИ-агенту полный доступ на чтение и запись к SAP ABAP-системе через ADT (ABAP Development Tools) с аутентификацией через SPNEGO/Kerberos single sign-on, X.509-сертификат клиента или OAuth 2.0 bearer-токен — без пароля где-либо в конфигурации. Пользователь и пароль по-прежнему доступны как запасной вариант, но не рекомендуются!

Он оборачивает 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 никогда не предлагаются 10 инструментов, которые ответили бы 400. На DEV остаётся 116.

Это SSO-форк mcp-abap-abap-adt-api от mario-andreschak. Основные отличия: Kerberos SSO вместо Basic Auth, инструменты JSON-RPC/RFC, маршрутизатор, построенный на определениях инструментов, и документированный справочник инструментов.

Документация

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

Возможности

• Два режима входа без пароля — SPNEGO/Kerberos с билетом вошедшего в систему пользователя Windows или X.509-сертификат клиента для сервисного или технического пользователя, у которого нет Kerberos-идентичности. Пароль SAP не хранится и не передаётся ни в одном из вариантов, и оба самовосстанавливаются при истечении сессии.

• Чтение любого объекта по имени — readAbapObject разрешает имя в исходный код одним вызовом; не нужно искать или вручную составлять ADT URL.

• Описание таблицы — describeAbapTable возвращает поля, DDIC-типы, ключевые флаги и таблицы проверки.

• Управление объектами — поиск, чтение, создание, изменение, удаление и активация ABAP-объектов.

• Обзор соглашения об именовании — searchPackages находит пакеты по шаблону (["ZPP_*","Z_PP*"]) и разворачивает каждый в его объекты, сгруппированные по типам, одним вызовом.

• Рабочий процесс с исходниками — блокировка → редактирование → проверка синтаксиса → активация → снятие блокировки, с обработкой транспортов.

• Интеллект кода — автодополнение, определения, ссылки на использование, ABAP Doc, pretty printer, ATC, ABAP Unit, рефакторинг (переименование, извлечение метода).

• Вызов RFC-функциональных модулей — callFunctionViaJsonRpc выполняет RFC-совместимый функциональный модуль и проверяет запрос по его реальной сигнатуре, прочитанной из системы.

• Пакетные RFC-вызовы в одной LUW — callFunctionsViaJsonRpc отправляет несколько функциональных модулей одним запросом, что позволяет BAPI обновления и его BAPI_TRANSACTION_COMMIT разделить одну LUW.

• Доступ к данным — tableContents и ad-hoc SELECT через runQuery.

• Вид на работающую систему — listLoggedOnUsers отвечает на вопрос «кто вошёл в систему» из TH_USER_LIST, тех же данных, что за SM04; readProfileParameters читает значения RZ11 за один круговой обход; а checkLogonConfiguration сообщает, какую аутентификацию система реально принимает.

• Встроенные навыки агента — 54 навыка в skills/: по ABAP (Clean ABAP, RAP, CDS, ATC, abapGit…) и по общей инженерии (TDD, ревью кода, диагностика ошибок), доступные как ресурсы и через readSkill.

• Самодокументируемость — приведённые ниже руководства раздаёт сам сервер как MCP-ресурсы (abap-adt://guides/…) и через инструмент readServerGuide, так что агент может найти рабочий процесс или аргумент посреди задачи, не покидая сессию.

Предварительные требования

• SAP ABAP-система, доступная по ADT. /sap/bc/adt должен быть активен в SICF. Для RFC-инструментов также должен быть активен /sap/gw/jsonrpc (SAP_GWFND), а вашему пользователю нужен S_RFC для вызываемых функциональных групп.

• Способ войти без пароля, один из:

  • Работающий Kerberos-вход — SAP-система должна принимать SPNEGO, и у вас должен быть действующий билет (klist). Это вариант по умолчанию, и как поставляется, он требует Windows: загрузочный скрипт обращается к C:\Windows\System32\curl.exe --negotiate, которому нужен бэкенд Schannel/SSPI от curl. На других платформах укажите SSO_CURL_PATH на curl, собранный с поддержкой GSS-API.

  • X.509-сертификат клиента — для сервисного или технического пользователя, у которого нет Kerberos-идентичности. Не требует ни curl, ни Windows. SAP должен быть настроен: порт ICM должен запрашивать сертификат (VCLIENT в icm/server_port_<n>, который переопределяет icm/HTTPS/verify_client), выпускающий ЦС должен быть доверенным в STRUST, а CERTRULE должен сопоставлять сертификат с пользователем. Полная настройка — включая то, как проверить её с этого сервера — в docs/Authentication.md.

  • OAuth 2.0-клиент — для SAP BTP ABAP-среды, где нет Kerberos-домена и нечего настраивать в ICM, или для локальной системы, публикующей ADT через SOAUTH2. Сервисный ключ 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.

Пакет npx mcp-abap-abap-adt-api на npm — это вышестоящий сервер и не включает 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 откладывает схемы и должен оставаться на настройке по умолчанию; модель на 8B с окном 128k тратит шестую часть своего контекста ещё до начала разговора, и именно отсюда берётся «один и тот же промпт срабатывает через раз».

ABAP_MCP_PROFILE — если не задан, значит all, так что существующая настройка не меняется.

В подсчёты входит healthcheck, который находится вне каждого профиля, потому что это инструмент, отвечающий на вопрос «какой профиль у меня запущен?».

Профиль — это не удобный фильтр. Инструмент вне активного профиля не отображается и не маршрутизируется, поэтому его нельзя вызвать — именно это делает analyst гарантией того, что ничто не изменит исходный код, а не просто меньшим меню. Вызовы вне профиля получают ошибку, которая об этом сообщает, а не «неизвестный инструмент», так что повторять попытки бессмысленно. Неизвестное имя профиля останавливает сервер при запуске, а не откатывается к all — молча обслуживать 129 инструментов того, кто просил 9, это ровно тот сбой, для предотвращения которого профили и существуют.

core мал, потому что один инструмент, editAbapSource, и есть цикл записи: блокировка, запись, активация, разблокировка, причём блокировка снимается даже при сбое на любом шаге. Четыре отдельных шага остаются в dev и all.

ABAP_MCP_MAX_RESPONSE_BYTES — список инструментов это фиксированная стоимость, которую профиль может уменьшить; ответ же ничем не ограничен. На core весь список инструментов занимает ~11 КБ, тогда как один adtDiscovery — ~42 КБ. Если переменная не задана, действует значение профиля (core — 24 000 байт, analyst — 32 000, dev — 48 000, all — без ограничения); 0 отключает ограничение.

Ответ, превышающий бюджет, удерживается и заменяется корректным JSON — status:"truncated", исходный bytes, budget, preview на 2 000 байт и nextStep — и никогда не обрезанным фрагментом, который не распарсился бы и лишь спровоцировал бы тот же самый повторный запрос.

ABAP_MCP_GATE — перед выводом чего-либо сервер спрашивает систему, что она поддерживает, и скрывает инструменты, чьи коллекции ADT отсутствуют. На DEV это 10 инструментов abapGit и 3 инструмента привязки сервисов, которые иначе отвечали бы HTTP 400. Это стоит одного обхода обнаружения на процесс, может только сократить список, а любой сбой оставляет все инструменты перечисленными. 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 переносится, но ACL SNC0 не участвует, а ICM требуется icm/HTTPS/verify_client. В docs/Authentication.md описаны различия, ловушка sapgenpse export_p12 / OpenSSL 3 и как читать отклонённый сертификат.

Клиент OAuth 2.0 для BTP и для SOAUTH2

Для среды SAP BTP ABAP или локальной системы, публикующей ADT за сервером авторизации. Указание идентификатора клиента переключает режим:

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.

Токен выполняет вход один раз. После этого сессионный cookie SAP несёт каждый запрос, как и в остальных режимах — так что токен, истекающий через пять минут, не проблема. Обратите внимание, что клиент OAuth 2.0 в AS ABAP является пользователем в SU01: неверный SAP_OAUTH_CLIENT_SECRET засчитывается в login/fails_to_user_lock как пароль, поэтому отклонённый запрос токена никогда не повторяется. Поток authorization-code не реализован — ему нужен браузер, а сервер, запущенный через stdio, не имеет возможности его открыть; выполните его один раз вручную и передайте refresh-токен. В 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

Сервер общается по MCP через stdio, так что публиковать порт не нужно — клиент запускает контейнер и общается с ним через 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 бы вычистил, приходит как есть. Пути Windows в .env нужно заменять на смонтированные. Kerberos — режим, которому от контейнера нужно больше всего, а OAuth — меньше всего: токен получается по сети, так что монтировать вообще ничего не нужно.

Режим сертификата — смонтируйте ключевой материал только для чтения, а также CA, подписывающий сертификат SAP, вместе с ним:

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 — в образе есть curl, собранный с GSS-API, и kinit, так что остаётся только область и учётные данные:

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

Три вещи, которые стоит знать, прежде чем к нему прибегать:

• Keytab, а не ваш собственный билет. Контейнер не может позаимствовать учётные данные сессии так, как это делает интерактивный вход. На хосте Linux вы можете смонтировать уже имеющийся кэш билетов (-v /tmp/krb5cc_1000:/krb5/ccache:ro -e KRB5CCNAME=FILE:/krb5/ccache), но он истекает вместе с хостом. С хоста Windows не работает ни то, ни другое: TGT живёт в кэше LSA и не может быть записан в файл — используйте режим сертификата, которому ничего из этого не нужно. Keytab — единственные учётные данные, которые работают без присмотра, и единственные, которые переживают время жизни билета.

• Проверяйте сертификат SAP или знайте, что вы этого не делаете. Образ доверяет только публичному пакету CA, поэтому внутренний CA, которому доверяет хост, здесь неизвестен, и рукопожатие завершается ошибкой UNABLE_TO_GET_ISSUER_CERT_LOCALLY. Смонтируйте корневой CA и укажите на него SAP_CA_FILE. Перенос настольного .env целиком скрывает это: NODE_TLS_REJECT_UNAUTHORIZED=0 — это настройка для разработки, и ей не место в развёрнутом образе.

• Собирайте из клона с --recurse-submodules. skills/Development — это подмодуль; без него в образе будет на 35 навыков меньше.

Образ основан на Debian, а не на Alpine, по одной причине: curl в Alpine собран без 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", "…": "…" } }

Затем каждый сервер сообщает о себе в instructions MCP, которые возвращает при подключении:

Этот сервер привязан к системе SAP DEV, клиент 100 (https://…:44301). Он не может переключить систему или клиент во время выполнения — оба зафиксированы окружением, в котором он был запущен. Если запрос называет другую систему или клиент, используйте MCP-сервер, настроенный для них; если ни один не зарегистрирован, скажите об этом, а не действуйте здесь.

Именно это позволяет агенту направить запрос «проверь это в DEV, клиент 200» нужному серверу, ничего не вызывая. healthcheck сообщает ту же идентичность для сервера, к которому нужно обратиться напрямую.

Декларация проверяется. SAP называет систему и клиента в сессионном cookie, который устанавливает при входе (SAP_SESSIONID_DEV_100), так что сервер знает, к чему на самом деле подключён. Если это расходится с SAP_SYSTEM_ID — например, скопированная запись, указывающая не на тот хост, — healthcheck несёт WARNING, и об этом громко пишется в журнал при запуске. За этим стоит следить, потому что все инструменты продолжают работать безупречно; просто в неправильной системе.

Краткий обзор

Читайте любой объект по имени — без обнаружения URL:

{"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 и его commit должны идти в одном пакете, иначе commit попадёт в собственную LUW, и изменения BAPI будут потеряны:

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

Полный цикл записи (блокировка → изменение → проверка → активация → разблокировка), отладчик, ATC и все остальные рабочие процессы описаны в docs/MCP-Tools.md §4.

Работа с объектами ABAP

Три инструмента покрывают большую часть того, что вам нужно, и каждый принимает имя, а не URL ADT:

{"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, длины, флаги ключей, элементы данных, домены и контрольные таблицы — контрольная таблица является целевой таблицей внешнего ключа, и это самый быстрый способ увидеть, как соединяются две таблицы. 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-тестов прогоняет обработчик от начала до конца на фиктивном узле SAP Gateway.

На реальной системе (требуется билет Kerberos) сквозная проверка выглядит так:

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

Он управляет собранным сервером через MCP stdio точно так же, как это делал бы клиент, и вызывает только read-only функциональные модули.

Добавление инструмента — это изменение одного файла — см. docs/MCP-Tools.md §10.

Устранение неполадок

Подробнее в docs/MCP-Tools.md §8.

Участие в разработке

1. Сделайте форк репозитория

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.