Skip to main content
Glama
palimkarakshay

abap-mcp

by palimkarakshay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get a dependency graph of ABAP objects

get_object_dependencies
Read-onlyIdempotent

Build a dependency graph from ABAP sources to sequence cloud migration and assess impact, covering referenced tables, function modules, inheritance, and calls. Optionally return Mermaid.

Instructions

Build a dependency graph over the provided ABAP sources for migration sequencing and impact reading: nodes are the provided objects plus every DB table / function module they reference (annotated with released-API state and CDS successor from the bundled SAP snapshot); edges are tiered by how they were derived — parser-level db-access and call-function references, structural inherits/implements from class definitions, and word-boundary references-textual matches between the provided objects. Optional Mermaid flowchart output. Use this when deciding what to migrate first (leaves before roots), what a rework might break, or which objects pull non-released tables into the picture — the sequencing companion to plan_cloud_migration. It is not a system where-used list: it only sees the text you pass, textual edges cannot see dynamic calls, and an absent edge is not proof of independence — a system's where-used and ATC remain authoritative. Example: get_object_dependencies({ "files": [ { "filename": "zcl_a.clas.abap", "source": "…" }, { "filename": "zcl_b.clas.abap", "source": "…" } ], "mermaid": true }).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesSource files to analyze, up to 32 per call, 100k chars each.
editionNoSAP 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
mermaidNoAlso return a Mermaid flowchart (graph LR) of the dependency graph for instant visualization.
abapVersionNoABAP language version used for parsing when extracting object references.v758

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
edgesYes
nodesYes
editionYesSAP edition the nodes' released-API states were checked against.
mermaidNoMermaid flowchart when requested.
scopeNoteYesExactly what the graph can and cannot claim.
releasedApiSnapshotDateYesDate of the bundled released-API snapshot behind the annotations.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.4
    • changedOutput schema / properties / nodes / items / properties / successor / description
      Previous value: -"Curated released CDS successor for a classic table."New value: +"Released successor for a classic table, when one is known."
    • addedOutput schema / properties / nodes / items / properties / successorSource
      Added value: +{
+  "description": "Where the successor came from: SAP's own snapshot or the curated fallback map.",
+  "enum": [
+    "sap",
+    "curated",
+    "none"
+  ],
+  "type": "string"
+}
  2. Changed3 schema fields changedv0.12.0
    • 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 the nodes' released-API states were checked against.",
+  "enum": [
+    "s4hc",
+    "btp",
+    "pce"
+  ],
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "nodes",
-  "edges",
-  "releasedApiSnapshotDate",
-  "scopeNote"
-]New value: +[
+  "nodes",
+  "edges",
+  "releasedApiSnapshotDate",
+  "edition",
+  "scopeNote"
+]
  3. Addedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing how edges are derived (parser-level db-access and call-function, structural inherits/implements, textual word-boundary matches), that textual edges cannot see dynamic calls, that an absent edge is not proof of independence, and that the bundled snapshot is edition-dependent.

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?

Purpose and node/edge semantics are front-loaded, and the worked example call clarifies the files shape efficiently. It is a very dense block of prose, but nearly every clause carries distinct information (derivation tiers, caveats, alternative tool).

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, the description need not explain return values, and it covers the remaining burden: what the graph contains, how edges are classified, the limits of textual analysis, and the edition-dependent release state. Nothing an agent needs to invoke it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents files, edition, mermaid, and abapVersion, making 3 the baseline. The description restates the Mermaid option and hints at the SAP snapshot/release state behind 'edition', but adds no syntax or format detail the schema lacks.

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 ('Build a dependency graph over the provided ABAP sources') and immediately defines the graph's nodes and tiered edges, so the agent knows exactly what is produced. It also distinguishes itself from siblings by naming plan_cloud_migration as its companion and explicitly disclaiming a system where-used list.

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?

Gives explicit triggering scenarios ('deciding what to migrate first (leaves before roots), what a rework might break, which objects pull non-released tables'), names the related tool plan_cloud_migration, and states a hard when-not ('not a system where-used list... a system's where-used and ATC remain authoritative').

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