Skip to main content
Glama
marianfoo

SAP Documentation MCP Server

by marianfoo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

sap_get_object_details

Retrieve release state, Clean Core level, successor objects, and cloud compliance for a specific SAP object by type and name, verifying safe use in BTP or S/4HANA Cloud ABAP development.

Instructions

GET SAP OBJECT DETAILS: sap_get_object_details(object_type="CLAS", object_name="CL_ABAP_REGEX")

Get complete release state details by actual object type and name, with TADIR fallback for compatibility. A TADIR container can contain multiple objects; use the actual type/name to select a specific member. A TADIR lookup returns one member. To list all members, use sap_search_objects with its TADIR type as object_type, name as query, and clean_core_level="D".

Use this tool when you: • Know a specific SAP object name and need to verify if it is released/deprecated/internal • Want to check Clean Core compliance: is this object allowed in BTP ABAP or S/4HANA Cloud? • Need to find the recommended successor object when a deprecated SAP API should be replaced • Want the full context of an object: software component, application component, Clean Core level (A/B/C/D), and release state • Are checking whether a specific table (MARA, VBAK), class (CL_*), interface (IF_*), or CDS view is safe to use in a clean core / cloud-ready ABAP development scenario

Clean Core levels: A=Released API (safe for cloud/BTP), B=Classic API (on-premise only), C=Internal/Stable (not for customer use), D=No API

Optionally pass target_clean_core_level to receive an explicit compliance verdict for that object.

PARAMETERS: • object_type (required): Actual or TADIR type, e.g. "FUNC", "BADI_DEF", "CDS_STOB", "CLAS", "DDLS", "FUGR" • object_name (required): Exact object name, e.g. "CL_ABAP_REGEX", "EKKO", "IF_OS_TRANSACTION" • system_type (optional, default: "public_cloud"): "public_cloud" | "btp" | "private_cloud" | "on_premise" • target_clean_core_level (optional): "A" or "B" — receive a compliance verdict against this target

RETURNS (JSON with): • found: boolean • objectType, objectName: Actual identity (TADIR identity for legacy records) • tadirObject, tadirObjName: Original TADIR container identity when available • state, cleanCoreLevel, cleanCoreLevelLabel • applicationComponent, softwareComponent • successor: successor classification and recommended replacement objects • successorObjects: full details of successor objects (if available in the dataset) • complianceStatus (if target_clean_core_level given): "compliant" | "non_compliant"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
object_nameYesExact object name, e.g. CL_ABAP_REGEX, EKKO, IF_OS_TRANSACTION.
object_typeYesActual or TADIR object type, e.g. FUNC, BADI_DEF, CDS_STOB, CLAS, DDLS, FUGR.
system_typeNoTarget SAP system type. Default: public_cloud.public_cloud
target_clean_core_levelNoOptional compliance target level. Returns complianceStatus: compliant or non_compliant.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.57
    • changedInput schema / properties / object_type / description
      Previous value: -"TADIR object type, e.g. CLAS, TABL, INTF, DDLS, FUGR, BDEF."New value: +"Actual or TADIR object type, e.g. FUNC, BADI_DEF, CDS_STOB, CLAS, DDLS, FUGR."
  2. Addedv0.3.50

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses the TADIR fallback behavior, that a TADIR lookup resolves to a single member while multiple members may exist, and enumerates the returned JSON fields including successor and complianceStatus. It does not cover error/not-found behavior or any auth or rate constraints, which is the remaining gap.

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

Conciseness4/5

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

Well front-loaded with a concrete invocation example followed by scoping rules, a use-when list, a level glossary, parameter notes, and a returns block. It is long, and the RETURNS block plus parameter bullet list partially duplicate the schema, but the structure keeps each section scannable and purposeful.

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?

There is no output schema, so the description must describe returns, and it does so field by field (found, objectType, tadirObject, state, cleanCoreLevel, applicationComponent, successor, complianceStatus). Combined with the Clean Core level glossary and system_type semantics, an agent has everything needed to call and interpret this tool.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains the distinction between 'actual' vs TADIR type for object_type selection and clarifies that target_clean_core_level triggers an explicit compliance verdict. Only minor value-add, but it goes past restating 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?

States a specific verb and resource ('Get complete release state details by actual object type and name') and immediately distinguishes itself from the sibling sap_search_objects by describing the TADIR fallback and the one-member-per-lookup behavior. An agent can tell what this returns (release state, Clean Core level, successor) without opening the 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?

Provides an explicit bulleted 'Use this tool when you:' list covering verification, Clean Core compliance, successor lookup, and full object context. It also names the alternative route explicitly ('To list all members, use sap_search_objects with its TADIR type as object_type, name as query, and clean_core_level="D"'), so the routing decision is unambiguous.

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

Deploy Server

Other Tools