When we ask an AI agent, “What is MARA’s successor in ABAP Cloud?” or when we develop in ABAP Cloud using AI development agents, we’ve realized that, without guidance, the AI can make mistakes and generate incorrect suggestions for objects.
In response to this need to ensure the reliability of the results, we decided to launch the MCP sap-released-objects.
Now it’s time for an (almost) objective analysis of our solution. We tested three methods on real-world cases and measured token consumption, reliability, and the completeness of the results:
Note: This analysis has no scientific value and is solely the result of manual tests conducted on Claude.
“What is the successor to MARA?”
The developer/consultant knows the technical name of the object and wants to know what to replace it with.
A: LLM only (without tools)
The agent responds directly based on its training data.
Result obtained:
MARA’s successor is I_PRODUCT.
Verdict:
- Tokens consumed: ~200 (output only)
- Primary successor found: yes (I_PRODUCT)
- Complete list: no, 1 successor out of 5
- Risk: potential hallucinations regarding lesser-known objects
The LLM is familiar with I_PRODUCT because it is a classic example found in many blogs. However, it consistently ignores the other four successors—I_PRODUCTPROCUREMENT, I_PRODUCTQM, I_PRODUCTSALES, and I_PRODUCTSTORAGE_2—even though they are present in the cloud repository.
B : Web search
The agent performs a web search for ‘MARA table successor ABAP Cloud released API’.
Result obtained:
The 10 results returned are SAP Community blogs, tutorials, and forums. MARA and I_PRODUCT are mentioned indirectly in some articles, but none of the results provide a complete, structured list of successors.
Verdict:
- Tokens consumed: ~4,500+ in input (raw results injected into the context) + ~500 in output
- Main successor found: yes (mentioned in blogs)
- Complete list: no: 1 to 2 successors detectable in the noise
- Risk: blogs sometimes outdated, very low signal-to-noise ratio
C : MCP sap-released-objects
The agent calls sap_find_successor(“MARA”, object_type=”TABL”).
Result obtained:
=== Successor Search for ‘MARA’ ===
— TABL MARA —
State: notToBeReleased (Level C)
Successor Type: multipleObjects
→ DDLS I_PRODUCT [released (Level A)]
→ DDLS I_PRODUCTPROCUREMENT [released (Level A)]
→ DDLS I_PRODUCTQM [released (Level A)]
→ DDLS I_PRODUCTSALES [released (Level A)]
→ DDLS I_PRODUCTSTORAGE_2 [released (Level A)]
Verdict:
- Tokens consumed: ~250 on input + ~300 on output
- Successors found: 5 out of 5
- Application component: LO-MD-MM
- Risk of hallucination: null : data from the official SAP Cloudification Repository
Comparison
| Criteria | LLM only | Web search | MCP server |
|---|---|---|---|
| Tokens used | ~200 | ~5 000 | ~550 |
| Successors found | 1/5 | 1-2/5 | 5/5 |
| Clean Core Level | Inconnu | Parfois mentionné | Oui |
| Cross-version comparison | Non | Non | 2020 → latest |
| Risk of hallucinations | Élevé | Moyen | Null |
| Up-to-date data | Cutoff LLM | Dépend des blogs | GitHub SAP live |
The key feature of sap-released-objects: semantic search
Let’s start with an example: “What objects are used for physical inventory?”
The developer doesn’t know the technical term; they just know they’re working on physical inventory and are looking for available APIs.
Problem: SAP technical names use abbreviations (PHYSICALINVENTORY, PHYSINVTRY, PHYS_INV…) that a human cannot guess.
A: LLM only
The agent is trying to list from memory the CDS views released for the physical inventory.
Result: The LLM can mention I_PHYSICALINVENTORYDOCUMENT if it appears in its training data, but it does not know the complete list and cannot distinguish between released and non-released objects. There is a high probability that it will invent object names.
B : Web search
Search: “physical inventory, CDS API, view, ABAP Cloud”.
Result: 10 results returned. None of the results mention the objects I_PHYSINVTRY* or I_PHYSICALINVENTORY*
C : MCP sap-released-objects
The agent calls sap_search_objects(query=“physical inventory”).
Result: 35 released items found, including:
I_EWM_PHYSINVTRYITEMROW (SCM-EWM, Level A)
I_PHYSICALINVTRYISACTVBLKD (MM-IM, Level A)
I_PHYSINVTRYBOOKSERIALNMBRTP (MM-IM-PI, Level A)
I_PHYSINVTRYCOUNTSERIALNMBRTP (MM-IM-PI, Level A)
I_PHYSINVTRYCOUNTSTS (MM-IM, Level A)
I_PHYSINVTRYCUBE (MM-IM, Level A)
I_PHYSINVTRYDELETIONSTS (MM-IM, Level A)
…
| Criteria | LLM only | Web search | MCP server |
|---|---|---|---|
| Found objects | 0-1 | 10 | 35 |
| SAP Abbreviation Lookup | Non | Non | Oui (fuzzy matching) |
| Filterable by component (MM-IM, EWM…) | Non | Non | Oui |
| Filterable by type (DDLS, BDEF, CLAS…) | Non | Non | Oui |
| Tokens used | ~200 | ~4 500+ | ~400 |
The MCP server indexes over 33,000 objects and appears to facilitate better navigation by business concept.
Beyond the successor: complementarity with other MCPs
Example : vibing-steampunk
The MCP sap-released-objects determines which object has been released or which is its successor. However, it cannot read the successor’s source code or rewrite code.
Meanwhile, vibing-steampunk is an ADT-to-MCP bridge that allows an agent to read, write, and deploy ABAP code directly into an SAP system.
When the two MCP servers are connected, the agent can execute a complete migration workflow in a single session:
Step 1: sap_find_successor(“MARA”) via sap-released-objects → 5 CDS views identified
Step 2: sap_get_object_details(“I_PRODUCT”, “DDLS”) → Level A, component LO-MD-MM
Step 3: GetSource(“I_PRODUCT”, “DDLS”) via vibing-steampunk → Complete CDS code with fields and associations
Step 4: The agent rewrites the SELECT * FROM MARA query using I_PRODUCT
Step 5: WriteSource + SyntaxCheck + Activate via vibing-steampunk → Code pushed to the dev system
Conclusion
The MCP server helps reduce your token usage, provides better search results, and offers additional features (bulk check, cross-version, component filtering).
The server is open source, so feel free to suggest improvements: github.com/ClementRingot/sap-released-objects-mcp-server