abap-mcp

Overview Schema Source Related Servers Discussions Admin

Check ABAP released-API status

check_released_api

Read-onlyIdempotent

Check whether ABAP objects are released, deprecated, or not-released for ABAP Cloud, including successors and API classification, using SAP's Cloudification list.

Instructions

Look up ABAP repository objects (DB tables, CDS view entities, function modules, classes, interfaces, …) in SAP's published ABAP Cloudification list and report, per object, whether it is a 'released' API (safe to use in ABAP Cloud / Clean Core), 'deprecated' (released but being retired), or 'not-released' (a classic/internal object that is not a public API — e.g. most classic DDIC tables) — with SAP's own successor(s) when the snapshot has any, a curated CDS successor hint otherwise, and a classicAPI/noAPI/internalAPI classification where SAP publishes one. This reflects SAP's official per-edition Cloudification lists as bundled in this package (default edition "s4hc", snapshot 2026-10-26); it ships offline with the server. Use this when you need to know if your code may reference a given object in ABAP Cloud, or which released CDS view to use instead of a classic table. This explicit lookup complements check_cloud_readiness's limited, source-extracted released-API observations and can check objects that do not appear in the supplied source. It does not connect to any SAP system, does not run ATC, and is only as current as the bundled snapshot — a target system's own released-API ATC check ("Usage of Released APIs (Cloudification Repository)" for SAP Cloud ERP Public Edition / "Usage of APIs (Cloudification Repository)" for SAP Cloud ERP Private Edition / on-premise, via variants such as ABAP_CLEAN_CORE_DEVELOPMENT / ABAP_CLEAN_CORE_READINESS) remains authoritative; treat an 'absent from the list' result as 'not-released as of the snapshot', not as proof. Example: check_released_api({ "objects": ["MARA", "I_Product", "BAPI_MATERIAL_GET_DETAIL"] }).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "objects": "<objects>"
    },
    "name": "check_released_api"
  }
}

Input Schema

Name	Required	Description	Default
`edition`	No	SAP edition of the bundled Cloudification snapshot to check against: "s4hc" (default, SAP Cloud ERP Public Edition), "btp" (SAP BTP ABAP environment), or "pce" (SAP Cloud ERP Private Edition / on-premise). Release state and successors can differ by edition — the same object may be released in one and not yet in another.	s4hc
`objects`	Yes	Objects to check, 1–200 per call. Each is a bare name string or a { name, type? } object, e.g. ["MARA", { "name": "I_Product", "type": "CDS_STOB" }].

Output Schema

Name	Required	Description
`source`	Yes	URL of the SAP Apache-2.0 source the snapshot was built from.
`edition`	Yes	SAP edition these results were checked against.
`results`	Yes
`snapshotDate`	Yes	Date of the bundled SAP Cloudification snapshot these results reflect.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.12.0Sep 12, 2026

addedInput schema / properties / edition

Added value: +{
+  "default": "s4hc",
+  "description": "SAP edition of the bundled Cloudification snapshot to check against: \"s4hc\" (default, SAP Cloud ERP Public Edition), \"btp\" (SAP BTP ABAP environment), or \"pce\" (SAP Cloud ERP Private Edition / on-premise). Release state and successors can differ by edition — the same object may be released in one and not yet in another.",
+  "enum": [
+    "s4hc",
+    "btp",
+    "pce"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / edition

Added value: +{
+  "description": "SAP edition these results were checked against.",
+  "enum": [
+    "s4hc",
+    "btp",
+    "pce"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / results / items / properties / classification

Added value: +{
+  "description": "SAP's classicAPI/noAPI/internalAPI classification for this object, from objectClassifications_SAP.json, when recorded.",
+  "enum": [
+    "classicAPI",
+    "noAPI",
+    "internalAPI"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / results / items / properties / successor / description

Previous value: -"Curated released CDS view-entity successor for a classic table, when one is known."New value: +"Released successor for a deprecated/classic object, when one is known — SAP's own, or the curated fallback (see successorSource)."

addedOutput schema / properties / results / items / properties / successorSource

Added value: +{
+  "description": "Where `successor` came from: SAP's own snapshot data, the curated table-successors fallback, or none available.",
+  "enum": [
+    "sap",
+    "curated",
+    "none"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / results / items / properties / successors

Added value: +{
+  "description": "Every SAP-published successor object for this record (there can be more than one), when the snapshot carries any.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "objectType": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "objectType",
+      "name"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "name",
-  "state",
-  "recorded"
-]New value: +[
+  "name",
+  "state",
+  "recorded",
+  "successorSource"
+]

changedOutput schema / required

Previous value: -[
-  "snapshotDate",
-  "source",
-  "results"
-]New value: +[
+  "snapshotDate",
+  "source",
+  "edition",
+  "results"
+]

First observedv0.4.5Jul 7, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the critical non-obvious traits: it is an offline bundled snapshot (edition default "s4hc", dated 2026-10-26), it contacts no SAP system, runs no ATC, is only as current as the snapshot, and an absent result means "not-released as of the snapshot" rather than proof. That is exactly the caveat an agent needs to avoid over-claiming a Clean Core verdict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded and nearly every clause carries information, but the whole thing is one dense run-on paragraph with deeply nested em-dash asides. The ATC variant names (ABAP_CLEAN_CORE_DEVELOPMENT / ABAP_CLEAN_CORE_READINESS) and the parenthetical edition mapping could be compressed or broken out without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description still pre-empts the interpretive questions (what the three states mean, when successors come from SAP vs a curated hint, staleness). Nothing an agent needs to call this correctly or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so edition values and the bare-string vs {name, type} union are already documented; the description adds an end-to-end example call showing both forms in practice. It does not restate the 1–200 item bound or when to supply `type` for ambiguous names, so it only modestly exceeds the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ("look up ABAP repository objects ... in SAP's published ABAP Cloudification list") and enumerates the exact output categories (released / deprecated / not-released) plus successor hints and classicAPI classification. It explicitly distinguishes itself from the closest sibling, check_cloud_readiness, so an agent can pick correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the triggering question ("Use this when you need to know if your code may reference a given object in ABAP Cloud, or which released CDS view to use instead of a classic table") and gives an explicit alternative and its trade-off: check_cloud_readiness is limited to source-extracted observations, whereas this tool can check objects absent from the source. It also sets the boundary against the target system's own ATC check as the authoritative source.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server