sap-abap-sql

SAP ABAP SQL（MCP 服务）

在 ABAP Open SQL 到达 SAP 的 ADT 数据预览控制台之前，对其进行检查和修正。

如果你曾让大模型连接本地部署的 SAP 系统，就会见过这些错误：

你发送的内容	SAP 的回应
SELECT SUM(netwr) FROM vbap	400 Unknown column name "SUM(NETWR)"
SELECT COUNT(DISTINCT kunnr) FROM vbak	400 ")" is invalid here (due to grammar)
SELECT a FROM t WHERE (x = '1' OR y = '2')	400 ") " was expected here.

三个错误，三条表面上的规则，一个真正的原因：解析器要求每个括号内侧都要有空格。 第三个错误甚至直接告诉了你。加上空格后，三个语句都能通过。

这些消息里没有任何一条说“加空格”，所以模型只能猜。在一次记录的会话中，同一条格式错误的语句连续发送了十次，每次只改变了一个字面值。两次会话中，211 次工具调用有 57 次失败，其中大多数都与方言有关。

这个服务了解这些规则，因此你的 Agent 不必重新摸索。

这是哪种方言

ADT 数据预览控制台（/sap/bc/adt/datapreview/freestyle），Agent 和 ADT 客户端通过 HTTP 读取表数据的地方。在 ABAP 程序内部编写的 Open SQL 是另一种方言：它有 INTO TABLE、UP TO n ROWS、@host 变量，而且没有字符数上限。不要将其用于程序源代码，并指望结果正确。

适用于本地部署的系统（ECC、S/4HANA 本地部署、私有云）。如果你使用的是带有规范 OData API 的 S/4HANA Cloud，则不需要这些内容。

它会接触我的系统吗？

只有你明确要求时才会，而且只会从你自己的机器发起。

四个工具中的三个是针对你传入的语句执行的纯函数：不建立连接、不使用凭据、不发起网络调用。它们是默认工具，无需任何配置即可运行。

第四个工具 abap_sql_query 会在你配置的系统上运行语句并返回行数据。凭据保存在你机器上此服务的环境中。不会经由任何第三方代理，也不会存储任何内容。

{
  "mcpServers": {
    "sap-abap-sql": {
      "command": "npx",
      "args": ["-y", "sap-abap-sql-mcp"],
      "env": {
        "SAP_URL": "https://your-system:44300",
        "SAP_USER": "...",
        "SAP_PASSWORD": "...",
        "SAP_HEADERS": "X-Your-Proxy-Token: ..."
      }
    }
  }
}

SAP_HEADERS 是可选项，每行填写一个 Name: value。本地部署的系统很少能直接访问：它们位于隧道或代理之后；如果隧道或代理需要自己的请求头才能放行，那么 SAP 还没收到请求，所有请求就都会被拒绝。其表现是出现一条内容恰好为“ADT is switched off”的 403 错误，但事实并非如此。

从设计上就是只读的：数据预览控制台无法写入，因此不存在可被误用的写入路径。

安装

{
  "mcpServers": {
    "sap-abap-sql": {
      "command": "npx",
      "args": ["-y", "sap-abap-sql-mcp"]
    }
  }
}

工具

工具	功能
abap_sql_prepare	返回要发送的语句；如果拒绝该语句，则指出需要如何修正
abap_sql_explain	解读被控制台拒绝的语句，但不对其进行改写
abap_sql_query	在你配置的系统上运行准备好的语句并返回行数据
abap_sql_rules	列出此方言与标准 SQL 的不同之处

所有工具均为只读，不会产生副作用。

abap_sql_prepare  SELECT COUNT(DISTINCT kunnr) FROM vbak
→ { "ok": true, "statement": "SELECT COUNT( DISTINCT kunnr ) FROM vbak", "length": 40, "limit": 255 }

abap_sql_prepare  SELECT a FROM t LIMIT 10
→ { "ok": false, "rule": "no-limit",
    "fix": "ABAP Open SQL has no LIMIT. Cap the result with the reader's row limit instead." }

连接时，服务器还会在 instructions 中提供这五条规则，因此客户端在编写任何内容之前就能获取这些规则。需要明确查看规则时，可以使用 abap_sql_rules。

它了解什么

圆括号间距，包括所有需要它的情况：聚合函数、DISTINCT、子查询、布尔分组。COUNT(*) 保持紧凑，因为解析器两种写法都能接受，而且每个字符都会占用下文所述的长度限制。

**255 个字符的上限。**控制台接受 255 个字符，拒绝 256 个字符，计算时会合并空白字符。换行并不会增加可用长度，而且检查发生在重写之后，因为添加空格会让语句变长。这会影响你规划查询的方式：任何实际查询都必须拆分，并由你在一侧进行联接。

LIMIT、DESC/ASC 和点限定字段都会被拒绝，并指出对应的 ABAP 形式。p.vbeln 不是解析器会宽容对待的拼写错误，而是 3 个词元。

字面量的位置。'PUMP (SPARE)' 中的圆括号是数据，两个连续空格也一样。系统能识别 ABAP 的两种字符串形式和注释形式，因此重写绝不会改变语句的含义。这正是正则表达式会悄无声息地处理错误的地方，而不是明确报错。

它不会替你做什么

有两项限制来自控制台，而非我们，它们决定了你能提出什么请求：

每条语句最多 255 个字符，因此任何实际查询都必须拆分成多条语句，并由你在一侧进行联接。不支持窗口函数、CTE 和累计总计。

**行数硬性限制为 5,000 行。**如果结果达到上限，系统会标记为 truncated，而不是当作完整结果返回，因为基于悄悄截断的结果在客户端计算总数，只会得到自信却错误的结果。这种失败情况比报错更糟。

如果你发现自己要拼接 4 条语句才能回答一个问题，那是控制台的限制，没有客户端能解决。

范围

它负责准备语句，并可选择执行语句。它不会浏览对象、执行 ABAP、写入任何内容，也不了解你的表代表什么。

如果你更愿意调用库而不是运行服务，方言逻辑位于 abap-sql 中。分词使用 abaplint 的词法分析器，它是 TypeScript 中唯一正确的 ABAP 分词器。

由 Daslab 构建。我们将 Agent 连接到本地部署的 ERP 系统。从网络外部连接到这类系统是另一个问题，我们提供了一篇免费的实用指南：通过 HTTP 连接本地部署的 S/4HANA。

发布

git tag v0.3.0 && git push --tags。CI 会检查标签是否与 package.json 一致、运行测试、使用 provenance 发布到 npm、构建 .mcpb 包，并将其附加到 GitHub release。

发布使用 npm trusted publishing，因此此仓库中没有令牌，也无需轮换。npm 通过 OIDC 信任此仓库和此工作流。

有两个步骤仍需手动完成，因为 CI 没有它们所需的凭据：MCP Registry（mcp-publisher publish）和 Smithery（smithery mcp publish）。

许可证

MIT