MCP serverMCP servertypeExposes tools to a coding agent over MCP.See every one →What this type is →independently maintainedindependently maintainedoriginPublished by one person or a small company outside SAP. Says nothing about quality; the readings say that.See every one →

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 ajson 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/mcp stay installed in the same system, its core restarted here rather than patched.

Facts

Last pushLicenceMIT

Where it sits

Lives in
Provides
Serve your application over MCPABAPServe your application over MCPcapabilityExposing selected application data and business operations to an AI agent through the Model Context Protocol. An application may also integrate remote services through [service integration](capability:service-integration), connecting its exposed contract with [agent access to your systems](capability:agent-systems-access). Development assistance belongs to [agent access to your code](capability:agent-code-access).
Requires
abapGitabapGitartifactthe way the SDK objects get into the target ABAP system; the repository is pulled into a package with abapGit, online or offline

Who is behind it

ABAP-AIABAP-AIOrganisationMaintains this
In the atlas: maintains 3
@abap-ai
maintainerBastianPersonContributes to this
In the atlas: contributes to 3
@wommel0
1 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

Connections2

Where abap-ai/mcp2 runsmcp2: docs/GettingStarted.md, checked 2026-10-21: “The server is now live at `POST /zmcp2/DEMO/GREETER`.”HTTPdocumentedrequiresYour MCP client, actorYour MCP clientabap-ai/mcp2, moduleabap-ai/mcp2abapGit, moduleabapGit
SAPnot SAP's, or the project's ownstated in the documentdocumented only

README

quoted from abap-ai/mcp2 under MIT, read
abap-ai/mcp2/README.mdOn GitHub

ABAP 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-28 draft 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 stateless 2026-07-28 protocol 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 sibling mcp2_tests repository. The original session-based SDK lives separately and is unaffected; this package uses the distinct mcp2 object 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:

Reference — design and internals:

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 initialize and modern per-request _meta negotiation served by the same zif_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_builder for tool schemas, zcl_mcp2_elicit_schema for flat elicitation forms), and typed input-request builders (zcl_mcp2_input_elicitation, zcl_mcp2_input_sampling) unified by zif_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, declare define_tools( ) once, and implement call_tool( ). The base derives supports_tools, tools/list, get_tool_schema, unknown-tool rejection, and default schema validation from the catalog. Advertised-schema violations are returned as isError tool 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-request params.task opt-in), era_is_modern, get_protocol_version, plus can_request_input / input_required for MRTR, let authors safely gate era- and client-dependent features instead of hitting a framework -32021/-32600. Of the features SEP-2577 deprecates in 2026-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 _meta parsing — client identity, negotiated protocol, log-level hints and W3C trace context are available through typed base-class getters.
  • serverInfo lives in _meta in the modern era. The 2026-07-28 draft moved serverInfo out of the top-level result and into _meta["io.modelcontextprotocol/serverInfo"] (the ResultMetaObject shape) on 2026-07-16, so the SDK emits it there on every modern result, server/discover included, and nowhere else (details). Legacy initialize is unaffected: serverInfo stays 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 install once, then npm run lint (abaplint, config in abaplint.json).
  • Behavior: the Jest integration suite in the sibling mcp2_tests repository, 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.

MIT, read

History

Latest

v1.0.0

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-Name is no longer required on tasks/get / tasks/update / tasks/cancel. A header that is sent must still match params.taskId (-32020), an absent one is accepted: the Tasks extension puts that MUST on the client, and this SDK reads every task from ZMCP2_TASKS, so there is no app-server affinity to protect. tools/call, prompts/get and resources/read still require the header.
  • Mcp-Name errors now name the body field the header has to carry (params.name, params.uri, params.taskId) instead of just reporting a mismatch.
  • server/discover no longer writes the superseded top-level serverInfo field. Modern server identity is now emitted only in _meta["io.modelcontextprotocol/serverInfo"], on every modern result, which is where the 2026-07-28 draft put it on 2026-07-16. The top-level write existed because every published TypeScript v2 SDK up to 2.0.0-beta.4 bundled a DiscoverResultSchema that required it; 2.0.0-beta.5 (2026-07-21) reads _meta instead, so the workaround is gone. Clients pinned to 2.0.0-beta.4 or earlier will misclassify the server as non-modern — upgrade them. Legacy initialize is unchanged: serverInfo stays a top-level result field there. No ABAP API change; get_title / get_description / get_website_url / get_icons behave 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, so WHERE task_id = task_id matched every row — foreign task reads and updates, unscoped CORS allowlists, arbitrary server classes. 7.5x was never affected.
  • zcl_mcp2_schema_builder_ddic passes a typed ddobjname instead of CONV #( ), which downported to TYPE undefined.
  • ZMCP2_CLEAR_TASKS no longer sets LDBNAME to &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 ROWS after ORDER BY, and trailing blanks. Lines over 255 characters abort the build instead of being silently truncated on import.
  1. v0.1.0

    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-28 draft generation (stateless, per-request _meta negotiation, server/discover) alongside the legacy era 2025-03-26 … 2025-11-25, from one server class.
    • Multi-round-trip requests (MRTR): inputRequired results carrying form elicitation, URL elicitation, or sampling, correlated by an opaque requestState the client echoes back.
    • Tasks extension in both eras — modern io.modelcontextprotocol/tasks and the legacy 2025-11-25 shape, 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: declare define_tools( ) once, implement call_tool( ); the base derives tools/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 _meta parsing.
    • Framework input validation: advertised-schema violations return isError tool 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_number is matched by get_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 by get_arg_string_table / _integer_table / _number_table / _boolean_table.
    • Schema builder covers the common JSON Schema vocabulary: title on every property, default on scalars (emitted even for 0 / false / empty string), and add_string_array / add_integer_array / add_number_array / add_boolean_array. Composition keywords, $ref and 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_tests repository covers both eras against the reference TypeScript SDK.
    Security
    • check_authorization on the server contract: an optional per-server access check that runs before the request body is parsed, so denial (HTTP 403) blocks every method including initialize and server/discover. It refines ICF logon and S_ICF service authorization, which gate the node itself — it does not replace them. The SDK ships no authorization object; v1's fixed ZMCP_SRV clashed 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/result on a non-terminal task answers -32600 instead of blocking; clients poll tasks/get.
    • JSON-RPC batches are rejected, including for 2025-03-26-pinned clients.
    • Modern results carry serverInfo both 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_SRV authorization object — v1 checked one in its HTTP handler; v2 offers the check_authorization hook instead so you can use your own object. Servers that used ZMCP_SRV to separate audiences across servers under one ICF node should port that distinction. Full mapping in docs/MigrationV1.md.

Serve your application over MCP
  1. abap-ai/mcpMCP server SDK written in ABAPfrom ABAP
  2. abap-agent-runtimeABAP-native MCP endpoint that drives opted-in abap2UI5 appsfrom ABAP
  3. API ManagementAPI proxies with security and traffic policies and Developer Hubfrom BTP/BAIP
  4. com.sap.cds:cds-adapter-mcpMCP adapter turning a CAP Java service into an MCP serverfrom CAP
  5. @cap-js/mcpExposes CAP services as MCP servers for AI agentsfrom CAP
  6. @gavdi/cap-mcpGenerates an MCP server from annotated CDS entities and actionsfrom CAP
  7. btp-cf-mcpMCP server for SAP BTP and Cloud Foundry acting as the logged-in userfrom BTP/BAIP
  8. MarkWuRY168/SAP_MCPMCP server publishing SAP functions as tools from config tablesfrom ABAP
  9. @neoimpulse/cap-js-mcpMCP server inside a CAP application with model and query toolsfrom CAP
  10. @odatano/core-mcpMCP server exposing the ODATANO Cardano-to-OData bridge as toolsfrom CAP
  11. @odatano/nightgate-mcpMCP server exposing the NIGHTGATE Midnight attestation layerfrom CAP
  12. @shahid.la/cds-db-nlquery-mcpMCP server answering plain-English questions against a CDS schemafrom CAP
  13. Skybuffer AI MCP serverABAP add-on serving business data and transactions as MCP toolsfrom ABAP
  14. cap-mcp-pluginMCP server generated from a CDS model, forked from @gavdi/cap-mcpfrom CAP

Details

Sources3
Added by handdiscovered herechecked
github.com/abap-ai/mcp2tree, pushes, contributors, CIchecked
README.mdquoted, and what the entry declareschecked

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
discovered viaAdded by hand
first seen in the atlas
ecosystem and domainabap, ai-and-agents
Flavors1
Standard ABAP
“ABAP **7.5x** classic (first iteration).” — abap-ai/mcp2 — README, Target / toolingchecked
Contributors1

From the repository’s contributor list, .

History in the atlas1
  1. First seen.
For your agent