abap-ai/mcp2
A stateless rewrite of the ABAP MCP server SDK: one ABAP server contract answering both the 2026-07-28 protocol draft and the legacy 2025 versions, with no sessions and no SSE.
A server implementation only, written in ABAP and installed with abapGit into a 7.5x system at the 7.52 language level or higher: you inherit from zcl_mcp2_tool_server_base, declare a tool catalog in define_tools( ), implement call_tool( ), add a row to the zmcp2_servers table, and the server answers at POST /zmcp2/{AREA}/{SERVER} under an ICF node whose own logon procedure is the only authentication. One zif_mcp2_server contract serves both protocol eras: the legacy 2025-03-26 to 2025-11-25 versions negotiated at initialize, and the 2026-07-28 draft negotiated per request through _meta, with the base class answering client_supports_elicitation, client_supports_sampling and client_supports_tasks for whichever client is in front of it. Tool arguments are validated before the handler runs, against schemas built with zcl_mcp2_schema_builder or derived from a DDIC structure. Beside tools it implements static resources and readable resource templates, prompts, argument completions, round-trips for elicitation and sampling, and a tasks extension whose rows live in zmcp2_tasks for background work. The package vendors ajsonajsonA JSON parser and serialiser for ABAP that parses into a flexible, unstructured node tree rather than a fixed target structure, converting to one only when asked through to_abap.independent, abap as zmcp2_ajson and keeps ICF and DDIC calls behind zif_mcp2_http_* and zif_mcp2_ddic, each with a 7.5x implementation; the distinct mcp2 object prefix lets the session-based abap-ai/mcpabap-ai/mcpAn MCP server SDK written in ABAP to run natively on the ABAP stack, so an ABAP system can expose its own prompts, resources and tools to an agent from inside itself.independent, abap stay installed in the same system, its core restarted here rather than patched.
Facts
Where it sits
Who is behind it
In the atlas: maintains 3@abap-aimaintainerBastianContributes to this
In the atlas: contributes to 3@wommel01 contributor
Before choosing this
Conditions
PracticalFunctional boundary
Stateless by design: with no Mcp-Session-Id and no SSE, notifications of any kind, resources/subscribe and stream-close cancellation are excluded, which the author states are protocol-level impossibilities on stateless ICF rather than gaps to be filled later within this design. ABAP Cloud is not supported and not planned, the stated reason being SAP pushing its own MCP strategy and features in BTP; the first iteration targets 7.5x classic, with 7.02 to 7.4x served from a separate generated downport repository. No authorization object and no default auth check are delivered, so a user who may call the ICF node may call every AREA/SERVER registered under it until check_authorization is redefined.
PolicySAP API Policy 4.2026a§ 1.1, 1.2, 2.2.2from Serve your application over MCPAn MCP server exposes an SAP API, or uses SAP APIs to supply tools, resources or data to an agent.
- § 1.1 Published APIs. Published APIs are made available for the documented purposes identified by SAP, including integration, extensions and data exchange.
- § 1.2 Non-Published APIs. Customer and third-party applications must not access non-published APIs except where documentation permits it or SAP otherwise authorizes it.
- § 2.2.2 AI call sequences and data extraction. Outside SAP-endorsed architectures, data services or expressly identified pathways, the policy prohibits specified agentic API use and systematic or large-scale extraction.
MCP does not replace the API's documented-use boundary. Check that every endpoint is published for the intended use and whether the policy's AI-call or extraction provisions apply to the design.
SAP API Policy 4.2026a →What it declares
Every artifact
- Type
- MCP server
- Origin
- Independently maintained
As an MCP server
- Transport
- HTTP
Connections
Exposing application data and operations to agents over MCP
Git client written in ABAP that runs inside the system
Download
Architecture
Download
POST /zmcp2/DEMO/GREETER.”README
quoted from abap-ai/mcp2 under MIT, readABAP Model Context Protocol Server SDK v2 (mcp2)
A stateless, rewrite of the ABAP Model Context Protocol
server SDK, targeting the upcoming 2026-07-28 protocol generation while staying downward
compatible with the legacy era (2025-03-26 … 2025-11-25).
MCP
2026-07-28draft synchronous request/response profile. SSE, subscriptions, streaming responses, sessions, and server-pushed notifications are unsupported. Legacy revisions are served statelessly with the latest legacy data shapes.
This is a server implementation only. It is stateless — no protocol sessions, no SSE — so notification- and subscription-based features are out of scope by design (see docs/ProtocolSupport.md).
Status:
1.0.0(changelog). Active v2 implementation for the stateless2026-07-28protocol generation. Protocol core, data classes, HTTP runtime, config/factory, DDIC tables, demo servers and the request/response Tasks extension are implemented and covered by abaplint plus the external Jest integration suite in the siblingmcp2_testsrepository. The original session-based SDK lives separately and is unaffected; this package uses the distinctmcp2object prefix so both can coexist in one ABAP system.
Main Differences from V1 MCP SDK
- 7.02 – 7.4x support ships as a separate generated downport repository, not from this one --> https://github.com/abap-ai/mcp2-702
- No sessions, etc.
- No default auth object and check delivered --> you must implement your own auth checks if required, see Configuration and security
- No table maintenance due to frequent install issues
Intentionally not supported
- ABAP Cloud - with SAP pushing towards using their MCP strategy and features in BTP I see no reason to put in the required effort
Documentation
User guide — building servers with the SDK:
- Getting started — install, ICF setup, first server
- Learning path — staged exercises from first tool to MRTR and tasks
- Demo servers — feature map and legacy/modern walkthrough
- Server identity and request context — metadata, capabilities, tracing, caching
- Tools — arguments, content blocks, structured output, validation
- Resources — resources, reads, templates
- Prompts — prompt templates and arguments
- Completions — argument autocompletion
- Schemas — schema builders (general / DDIC / elicitation) + validator
- Input required (MRTR) — elicitation, sampling, URL mode
- Tasks — long-running background work
- Configuration and security — tables, CORS, auth, error mapping
- Troubleshooting — symptom-first index of common failures
- Migrating from v1 — what changes, what is dropped, suggested order
Reference — design and internals:
- Class reference — every public class, what it is for, where it is explained
- Architecture — design, packages, eras, request flow
- Protocol support — versions, methods, what is excluded and why
- Conversion — per-field data-class conversion conventions
- Platform abstraction — HTTP/DDIC wrapping and the ABAP Cloud roadmap
Design at a glance
- Stateless only — every request is self-contained; no
Mcp-Session-Id, no session tables. - One server contract, two protocol eras — legacy
initializeand modern per-request_metanegotiation served by the samezif_mcp2_server. - Typed authoring surface — common server-authoring paths need no hand-written JSON: typed
request getters (
require_arg_string,get_arg_string_or,bind_arguments), typed response factories (zcl_mcp2_resp_call_tool=>text,=>error_text,=>structured_data) and full-control builders (add_resource,add_resource_link,set_structured_data) with typed content annotations (zif_mcp2_content), fluent schema builders (zcl_mcp2_schema_builderfor tool schemas,zcl_mcp2_elicit_schemafor flat elicitation forms), and typed input-request builders (zcl_mcp2_input_elicitation,zcl_mcp2_input_sampling) unified byzif_mcp2_input_request. UI icons are typed everywhere the spec allows them: serverInfo (get_icons), tools, prompts, resources, resource templates and resource links (zif_mcp2_content=>icons). Pre-built ajson remains an escape hatch for rich prompt content and custom extensions. - Tool catalog base — inherit from
zcl_mcp2_tool_server_base, declaredefine_tools( )once, and implementcall_tool( ). The base derivessupports_tools,tools/list,get_tool_schema, unknown-tool rejection, and default schema validation from the catalog. Advertised-schema violations are returned asisErrortool results in both eras; structurally malformed calls and unknown tools remain-32602. - Era-aware capability checks on the base class —
client_supports_elicitation,client_supports_elicit_url,client_supports_sampling,client_supports_tasks(modern: declared extension; legacy: per-requestparams.taskopt-in),era_is_modern,get_protocol_version, pluscan_request_input/input_requiredfor MRTR, let authors safely gate era- and client-dependent features instead of hitting a framework-32021/-32600. Of the features SEP-2577 deprecates in2026-07-28, Roots and Logging are not implemented; Sampling is kept (as an MRTR input builder) because it is the only key-less LLM access path from ABAP. - Request context without
_metaparsing — client identity, negotiated protocol, log-level hints and W3C trace context are available through typed base-class getters. serverInfolives in_metain the modern era. The2026-07-28draft movedserverInfoout of the top-level result and into_meta["io.modelcontextprotocol/serverInfo"](theResultMetaObjectshape) on 2026-07-16, so the SDK emits it there on every modern result,server/discoverincluded, and nowhere else (details). Legacyinitializeis unaffected:serverInfostays a plain top-level field there.- Conversion in the data class — explicit per-field JSON↔ABAP; central code only for the JSON-RPC envelope and the modern result stamp.
Target / tooling
- ABAP 7.5x classic (first iteration). abaplint
v752. - ABAP 7.02 – 7.4x via a generated downport, published as a separate abapGit repository. Cloud-ready not planned.
- Distributed via abapGit.
Used ABAP open-source projects
- ajson — JSON library, vendored as
zmcp2_ajson(MIT). - abaplint — linting and transpiler-based unit tests.
- abapGit — source control.
More awesome ABAP projects at dotabap.org.
Development checks
- Static check:
npm installonce, thennpm run lint(abaplint, config in abaplint.json). - Behavior: the Jest integration suite in the sibling
mcp2_testsrepository, run against an ABAP system serving the SDK and its test servers. It covers both protocol eras against the reference TypeScript SDK plus raw-HTTP wire checks. - ABAP unit tests run in the ABAP system (SE80/ADT); the transpiler-based local run only covers a subset (no database, vendored-ajson unicode test excluded).
License
MIT. Vendored dependencies retain their original licenses; see THIRD_PARTY_NOTICES.md.
History
Fixes 4, Other 3
Notes
First stable release, cut alongside the 2026-07-28 spec generation. Everything below is relative to the 0.1.0 beta.
Protocol
Mcp-Nameis no longer required ontasks/get/tasks/update/tasks/cancel. A header that is sent must still matchparams.taskId(-32020), an absent one is accepted: the Tasks extension puts that MUST on the client, and this SDK reads every task fromZMCP2_TASKS, so there is no app-server affinity to protect.tools/call,prompts/getandresources/readstill require the header.Mcp-Nameerrors now name the body field the header has to carry (params.name,params.uri,params.taskId) instead of just reporting a mismatch.server/discoverno longer writes the superseded top-levelserverInfofield. Modern server identity is now emitted only in_meta["io.modelcontextprotocol/serverInfo"], on every modern result, which is where the2026-07-28draft put it on 2026-07-16. The top-level write existed because every published TypeScript v2 SDK up to2.0.0-beta.4bundled aDiscoverResultSchemathat required it;2.0.0-beta.5(2026-07-21) reads_metainstead, so the workaround is gone. Clients pinned to2.0.0-beta.4or earlier will misclassify the server as non-modern — upgrade them. Legacyinitializeis unchanged:serverInfostays a top-level result field there. No ABAP API change;get_title/get_description/get_website_url/get_iconsbehave exactly as before.
Fixed (downport only, 7.02 – 7.4x)
- Open SQL host variables named like a column of the table they address now go through renamed
locals (
task_id_arg,area_arg,server_arg). Without the@escape the column wins, soWHERE task_id = task_idmatched every row — foreign task reads and updates, unscoped CORS allowlists, arbitrary server classes. 7.5x was never affected. zcl_mcp2_schema_builder_ddicpasses a typedddobjnameinstead ofCONV #( ), which downported toTYPE undefined.ZMCP2_CLEAR_TASKSno longer setsLDBNAMEto&NC&("local database &NC& is unknown").- The downport now post-processes what abaplint leaves in strict-syntax form: commas in
UPDATE … SET,UP TO n ROWSafterORDER BY, and trailing blanks. Lines over 255 characters abort the build instead of being silently truncated on import.
Security 1, Other 19
Notes
First beta of the v2 SDK. This is a from-scratch rewrite of the ABAP MCP server SDK, not an upgrade of the v1 package — see docs/MigrationV1.md.
Protocol
- Serves the
2026-07-28draft generation (stateless, per-request_metanegotiation,server/discover) alongside the legacy era2025-03-26…2025-11-25, from one server class. - Multi-round-trip requests (MRTR):
inputRequiredresults carrying form elicitation, URL elicitation, or sampling, correlated by an opaquerequestStatethe client echoes back. - Tasks extension in both eras — modern
io.modelcontextprotocol/tasksand the legacy2025-11-25shape, including task-scoped input requests. - Header mirroring (
Mcp-Method,Mcp-Name,Mcp-Param-*) with body-as-source-of-truth validation. - Spec-correct error codes
-32020/-32021/-32022, replacing v1's non-standard-32001/-32004.
Authoring
zcl_mcp2_tool_server_base: declaredefine_tools( )once, implementcall_tool( ); the base derivestools/list, schema lookup, unknown-tool rejection and input validation.- Common server-authoring paths need no hand-written JSON — typed request getters, response factories and builders, fluent schema builders, typed input-request builders, typed content annotations and icons. Pre-built ajson remains available for rich prompt content and custom extensions.
- Era-aware capability helpers (
client_supports_elicitation/_elicit_url/_sampling/_tasks,can_request_input,era_is_modern) so handlers gate features instead of hitting framework errors. - Request context — client identity, protocol, log level, W3C trace context — via typed getters,
with no
_metaparsing. - Framework input validation: advertised-schema violations return
isErrortool results in both eras; malformed calls and unknown tools remain-32602. - Schema builder and request accessors are symmetric — every shape you can declare has a typed
reader.
add_numberis matched byget_arg_number/_or/require_(decfloat34, converted from the raw JSON literal so decimals are not rounded through a binary float), and each primitive-array builder byget_arg_string_table/_integer_table/_number_table/_boolean_table. - Schema builder covers the common JSON Schema vocabulary:
titleon every property,defaulton scalars (emitted even for0/false/ empty string), andadd_string_array/add_integer_array/add_number_array/add_boolean_array. Composition keywords,$refand dialect negotiation remain deliberately out of scope.
Structure
- Stateless by construction: no sessions, no
Mcp-Session-Id, no session tables. - JSON↔ABAP conversion localized per data class; only the JSON-RPC envelope and the modern result stamp are central.
- Environment-sensitive calls (HTTP, DDIC) behind interfaces with 7.5x implementations, so an ABAP Cloud port is a factory change.
- Full dispatch path unit-testable without ICF; external Jest integration suite in the sibling
mcp2_testsrepository covers both eras against the reference TypeScript SDK.
Security
check_authorizationon the server contract: an optional per-server access check that runs before the request body is parsed, so denial (HTTP 403) blocks every method includinginitializeandserver/discover. It refines ICF logon andS_ICFservice authorization, which gate the node itself — it does not replace them. The SDK ships no authorization object; v1's fixedZMCP_SRVclashed with customer naming conventions, so servers bring their own where one node hosts servers with different audiences.
Not implemented, by design
Server-sent notifications of any kind,
subscriptions/listen,resources/subscribe, SSE, sessions, logging, and roots. All require a server→client stream or stored session state. See docs/ProtocolSupport.md.Known deviations
tasks/resulton a non-terminal task answers-32600instead of blocking; clients polltasks/get.- JSON-RPC batches are rejected, including for
2025-03-26-pinned clients. - Modern results carry
serverInfoboth top-level and in_meta, because released TypeScript v2 SDKs still require the top-level field. To be dropped once a released SDK reads_meta.
Differences from the v1 SDK
No OAuth layer or request-nonce table, and no fixed
ZMCP_SRVauthorization object — v1 checked one in its HTTP handler; v2 offers thecheck_authorizationhook instead so you can use your own object. Servers that usedZMCP_SRVto separate audiences across servers under one ICF node should port that distinction. Full mapping in docs/MigrationV1.md.- Serves the
Others providing
Compare all 15 on the Serve your application over MCP page →- abap-ai/mcpabap-ai/mcpAn MCP server SDK written in ABAP to run natively on the ABAP stack, so an ABAP system can expose its own prompts, resources and tools to an agent from inside itself.independent, abapMCP server SDK written in ABAPfrom ABAP
- abap-agent-runtimeabap-agent-runtimeAn ABAP-native MCP endpoint inside the SAP system: an agent reads the screen of an opted-in abap2UI5 app as structured data, fills its fields and fires its events as the logged-on SAP user.community org, abapABAP-native MCP endpoint that drives opted-in abap2UI5 appsfrom ABAP
- API ManagementAPI ManagementAPI proxies in front of backend services, with security and traffic management policies attached to them, and Developer Hub where consumers subscribe.sap official, btpAPI proxies with security and traffic policies and Developer Hubfrom BTP/BAIP
- com.sap.cds:cds-adapter-mcpcom.sap.cds:cds-adapter-mcpThe MCP protocol adapter for CAP Java, serving an @mcp-annotated Application Service as an MCP server with three generated tools, describe, query and call, and data changes only through unbound actions.sap official, capMCP adapter turning a CAP Java service into an MCP serverfrom CAP
- @cap-js/mcp@cap-js/mcpA CAP plugin that serves an @mcp-annotated service over MCP with three generated tools, describe, query and call_action, and writes its endpoint into the local agent's configuration in development.sap official, capExposes CAP services as MCP servers for AI agentsfrom CAP
- @gavdi/cap-mcp@gavdi/cap-mcpGenerates an MCP server from the CDS model — annotated entities become resources and annotated actions become tools, so an agent reaches the service without a second server being written.independent, capGenerates an MCP server from annotated CDS entities and actionsfrom CAP
- btp-cf-mcpbtp-cf-mcpAn MCP server over an SAP BTP account and its Cloud Foundry runtime that acts as the person who logged in, so their own global-account and space roles decide what an agent can see.independent, btpMCP server for SAP BTP and Cloud Foundry acting as the logged-in userfrom BTP/BAIP
- MarkWuRY168/SAP_MCPMarkWuRY168/SAP_MCPPublishes SAP system functions as MCP tools from configuration tables held inside the SAP system, so adding a tool is a configuration change rather than a code change.independent, abapMCP server publishing SAP functions as tools from config tablesfrom ABAP
- @neoimpulse/cap-js-mcp@neoimpulse/cap-js-mcpAn MCP server inside a CAP application, with default tools that read the running model and query entities, plus configurable application tools, prompts and resources.independent, capMCP server inside a CAP application with model and query toolsfrom CAP
- @odatano/core-mcp@odatano/core-mcpMCP server exposing ODATANO — the Cardano-to-OData bridge built on CAP — to an agent, so the chain is reachable as tools rather than as a REST client.independent, capMCP server exposing the ODATANO Cardano-to-OData bridge as toolsfrom CAP
- @odatano/nightgate-mcp@odatano/nightgate-mcpMCP server exposing NIGHTGATE, the Midnight blockchain attestation layer, as agent tools — the companion to the CAP indexer plugin of the same name.independent, capMCP server exposing the NIGHTGATE Midnight attestation layerfrom CAP
- @shahid.la/cds-db-nlquery-mcp@shahid.la/cds-db-nlquery-mcpMCP server that answers plain-English questions against the entities in db/schema.cds — it discovers the schema, generates CQN-backed SQL with real joins, and returns rows.independent, capMCP server answering plain-English questions against a CDS schemafrom CAP
- Skybuffer AI MCP serverSkybuffer AI MCP serverAn ABAP add-on that serves SAP business data, transactions and development context as MCP tools from an ICF node inside SAP ECC and S/4HANA, each call running as the signed-in user under PFCG authorization checks.independent, abapABAP add-on serving business data and transactions as MCP toolsfrom ABAP
- cap-mcp-plugincap-mcp-pluginGenerates an MCP server from a CDS model: annotated entities become MCP resources, functions and actions become tools, and services can expose reusable prompt templates. A fork of @gavdi/cap-mcp that adds an OAuth proxy, IAS client registration and draft-lifecycle tools.independent, capMCP server generated from a CDS model, forked from @gavdi/cap-mcpfrom CAP
Details
Sources
Sources are graph entities: the same page may back several entries, and an unreachable source flags every row that rests on it.
Compatibility and provenance
Flavors
“ABAP **7.5x** classic (first iteration).” — abap-ai/mcp2 — README, Target / tooling
Contributors
History in the atlas
- First seen.
For your agent
- Ref
artifact:abap-ai-mcp2- JSON
- /artifacts/abap-ai-mcp2.json
- MCP
- Connecting an agent