状态： 实验性。请谨慎用于生产系统。

ABAP ADT MCP 服务器

一个 MCP 服务器，通过 ADT（ABAP 开发工具）为 AI 代理提供对 SAP ABAP 系统的完整读写访问，使用 SPNEGO/Kerberos 单点登录、X.509 客户端证书或 OAuth 2.0 不记名令牌进行身份验证——配置中无需任何密码。用户名和密码仍可作为回退方案，但不推荐！

它封装了 abap-adt-api，并添加了 ADT 本身无法做到的一件事：调用支持 RFC 的函数模块，通过 SAP Gateway JSON-RPC 2.0 服务实现。

128 个工具——对象增删改查、源代码编辑、锁、传输请求、激活、语法检查、代码补全、ABAP 单元测试、ATC、DDIC、abapGit、重构、跟踪、调试器和 RFC 调用。

客户端实际能看到的工具数量要少得多，原因有二。配置文件（ABAP_MCP_PROFILE）用表面换取上下文：core 列出 9 个工具，而 all 列出 129 个，对于无法按需获取工具模式的客户端，每轮对话分别约为 2,700 个令牌和约 17,800 个令牌。此外，服务器在列出任何内容之前会询问系统支持什么，因此没有 abapGit 插件的版本永远不会被提供那 10 个会返回 400 错误的工具。在 DEV 系统上，这剩下 116 个。

这是 mario-andreschak 的 mcp-abap-abap-adt-api 的 SSO 分支。主要区别：使用 Kerberos SSO 而非基本身份验证、JSON-RPC/RFC 工具、从工具定义派生的路由器，以及文档化的工具参考。

文档

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

功能特性

• 两种无密码登录模式——使用已登录 Windows 用户票证的 SPNEGO/Kerberos，或为没有 Kerberos 身份的服务或技术用户使用 X.509 客户端证书。无论哪种方式，都不会存储或发送 SAP 密码，并且两者在会话过期时都能自愈。

• 按名称读取任何对象——readAbapObject 通过一次调用将名称解析为源代码；无需发现或手工构造 ADT URL。

• 描述表——describeAbapTable 返回字段、DDIC 类型、键标志和检查表。

• 对象管理——搜索、读取、创建、修改、删除和激活 ABAP 对象。

• 调查命名约定——searchPackages 按模式查找包（["ZPP_*","Z_PP*"]），并通过一次调用将每个包展开为其按类型分组的对象。

• 源代码工作流——锁定 → 编辑 → 语法检查 → 激活 → 解锁，并处理传输请求。

• 代码智能——补全、定义、使用引用、ABAP 文档、代码格式化、ATC、ABAP 单元测试、重构（重命名、提取方法）。

• 调用 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 身份的服务或技术用户。既不需要 curl 也不需要 Windows。SAP 必须进行相应配置：ICM 端口必须请求证书（icm/server_port_<n> 中的 VCLIENT，它会覆盖 icm/HTTPS/verify_client），在 STRUST 中信任颁发 CA，以及映射到用户的 CERTRULE。完整设置——包括如何从此服务器检查这些设置——请参阅 docs/Authentication.md。

  • OAuth 2.0 客户端——适用于 SAP BTP ABAP 环境（没有 Kerberos 领域，也没有可配置的 ICM），或通过 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 模型在对话开始前就花费了其上下文的六分之一，这就是"相同的提示词只有一半时间有效"的原因。

ABAP_MCP_PROFILE——未设置时默认为 all，因此现有配置无需更改。

计数包含 healthcheck，它不属于任何 profile，因为它是回答“我现在运行的是哪个 profile？”的工具。

Profile 不是一个便利过滤器。不在活动 profile 中的工具不会被列出，也不会被路由，因此无法被调用——这正是 analyst 能保证没有任何东西会编辑源代码，而不只是一个更小的菜单的原因。超出 profile 的调用会收到一个明确说明此情况的报错，而不是“unknown tool”，所以没有必要重试。无法识别的 profile 名称会在启动时让服务器停止，而不是回退到 all——默默地将 129 个工具提供给只要求 9 个的对象，正是 profile 存在所要防止的确切失败。

core 很小，因为一个工具 editAbapSource 就是整个写入周期：锁定、写入、激活、解锁，即使某一步失败也会释放锁。四个独立的步骤保留在 dev 和 all 中。

ABAP_MCP_MAX_RESPONSE_BYTES —— 工具列表是 profile 可以缩减的固定开销；而回答是不设上限的。在 core 上，整个工具列表约为 ~11KB，而一次 adtDiscovery 约为 ~42KB。未设置时遵循 profile（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 上，那就是 10 个 abapGit 工具和 3 个 service-binding 工具，否则它们会返回 HTTP 400。它每个进程多花一次 discovery 往返，只会让列表变短，而且任何失败都会让所有工具继续被列出。ABAP_MCP_GATE=off 可跳过此检查。

healthcheck 会报告全部三项：活动 profile、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 的陷阱，以及如何解读被拒绝的证书。

OAuth 2.0 客户端，用于 BTP 和 SOAUTH2

适用于 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 中注册的那个。

**token 只登录一次。**之后，SAP 会话 cookie 承载每个请求，就像其他模式一样——所以一个五分钟后过期的 token 不是问题。请注意，AS ABAP 上的 OAuth 2.0 客户端在 SU01 中就是一个用户：错误的 SAP_OAUTH_CLIENT_SECRET 会像密码一样计入 login/fails_to_user_lock，因此被拒绝的 token 请求绝不会被重试。授权码流程没有实现——它需要浏览器，而通过 stdio 启动的服务器 无法打开浏览器；请手动完成一次，然后把 refresh token 传入。 docs/Authentication.md §11 有详细信息，包括哪些失败会被锁存以及为什么。

密码，在没有其他办法时

对于既没有 Kerberos 也没有证书的系统——沙箱、试用版、域外的任何东西：

SAP_USER=CLAUDEAGENT
SAP_PASSWORD=<the password>

**最后的手段，与其他两种不可互换。**缺失的 ticket 或未映射的证书会被直接拒绝；而错误的密码会计入 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 驱动它。

对于每一轮都携带全部工具 schema 的客户端，在同一个块中添加一个 profile：

"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 要求最少：token 通过网络获取，所以根本不需要挂载任何东西。

证书模式 —— 以只读方式挂载密钥材料，以及签署 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 构建的 curl 和 kinit，所以剩下的就是一个 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

在你使用它之前，有三件事需要知道：

• keytab，而不是你自己的 ticket。 容器无法像交互式登录那样借用会话的凭据。在 Linux 主机上，你可以挂载已有的 ticket 缓存（-v /tmp/krb5cc_1000:/krb5/ccache:ro -e KRB5CCNAME=FILE:/krb5/ccache），但它会随主机的缓存一起过期。在 Windows 主机上，两种方式都不行：TGT 存在于 LSA 缓存中，无法写入文件——请使用证书模式，它完全不需要这些。keytab 是唯一可以无人值守运行的凭据，也是唯一比 ticket 生命周期更持久的凭据。

• 验证 SAP 的证书，或者明白你没有在验证。 镜像只信任公共 CA 捆绑包，因此主机信任的内部 CA 在这里是未知的，握手会失败并报 UNABLE_TO_GET_ISSUER_CERT_LOCALLY。挂载根 CA 并将 SAP_CA_FILE 指向它。把桌面端的 .env 原样带进来反而会掩盖这个问题：NODE_TLS_REJECT_UNAUTHORIZED=0 是开发环境设置，在部署镜像中没有立足之地。

• 从 --recurse-submodules 的克隆来构建。 skills/Development 是一个子模块；没有它，镜像会少带 35 个 skills。

镜像选择 Debian 而不是 Alpine，原因只有一个：Alpine 的 curl 在构建时没有 GSS-API，而这样的 curl 不会失败——它只是从不发送 token，SAP 返回的 401 与过期 ticket 产生的 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 服务器；如果没有注册任何服务器，请如实说明，而不要在这里执行操作。

这样，agent 就能在不调用任何工具的情况下，把“请在 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"}}
]}}

完整的写入周期（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 类型、长度、键标志、数据元素、域和检查表——检查表是外键目标，是查看两个表如何连接的最快方式。objectStructure 对表不返回字段，tableContents 返回行而非定义，因此两者都无法回答"这个表长什么样"。

值得写入客户端系统提示词的规则

• 优先使用按名称的工具。 仅当需要中间结果时才回退到 searchObject → objectStructure → getObjectSource。切勿手工构造 /sap/bc/adt/... 路径。

• 高效选择。 SAP 表很大。始终用 WHERE 子句约束 SELECT，并在其他情况下使用 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 中产生任何变化。本地副本仅用于差异比较，仅此而已。

早期 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 驱动构建后的服务器，并且只调用只读函数模块。

添加一个工具只需改动一个文件——参见 docs/MCP-Tools.md §10。

故障排查

更多内容参见 docs/MCP-Tools.md §8。

贡献

1. Fork 该仓库

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。