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 provided ABAP sources to plan migration order and assess impact, showing referenced tables, function modules, and released-API state.

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. 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"
+]
  2. Addedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses key limits: it only sees the passed text, textual edges cannot see dynamic calls, an absent edge is not proof of independence, and system where-used/ATC remain authoritative. This is exactly the behavioral context an agent needs.

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?

Front-loaded with purpose, node/edge semantics, then caveats and a worked example. It is dense and long but each clause adds real information; the trailing JSON example is somewhat verbose but illustrative.

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 covers scope, semantics, limitations, edition sensitivity, and alternatives. Complete for this complexity.

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 coverage is 100%, so the schema already documents files, edition, mermaid, and abapVersion thoroughly. The description adds only the conceptual framing (provided objects, optional Mermaid output) and an example, which is a baseline 3 when the schema does the heavy lifting.

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?

Names a specific verb and resource (build a dependency graph over provided ABAP sources) and precisely defines both node and edge semantics, including edge tiers. This clearly distinguishes it from siblings like check_cloud_readiness or plan_cloud_migration.

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 use cases (deciding what to migrate first, impact of a rework, finding non-released tables), names the companion tool plan_cloud_migration, and states what it is NOT (a system where-used list). Nothing is left to inference.

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