mcp-abap-abap-adt-api

impactOf

Read-only

Find all objects and methods that depend on a specific ABAP object or method, showing the package tree and filtering test or standard SAP objects to assess change impact.

Instructions

What depends on an object, or on one method of it: the objects that use it, the places inside them, and the package each belongs to. This is usageReferences rolled up into an answer that can be read - that call returns a tree of package, object and member rows, which for a widely used class means hundreds of rows and over a hundred thousand characters for a list of forty objects. Usages in test includes are marked as such, standard SAP objects are left out unless asked for, and depth=2 follows the callers one step further to show what depends on them in turn. A method with no callers looks the same as one reached only dynamically, so an empty answer says so rather than reading as proof.

Input Schema

TableJSON Schema

Name	Required	Description
`depth`	No	1 (default) for what uses the object; 2 also reports what uses those, with the object each was reached through.
`snippets`	No	Also fetch the source snippet of each place actually listed (one more backend call, larger answer). Only covers depth 1 - indirect (depth=2) places never get snippets.
`objectUrl`	No	ADT object URL, for a type objectName cannot address.
`maxObjects`	No	How many objects to list. Default 100.
`methodName`	No	Narrow it to one method of the class or interface. The position inside the source is worked out here.
`objectName`	No	Object name, e.g. ZCL_APP_RETURN. Use with objectType.
`objectType`	No	ADT type: CLAS/OC, INTF/OI, PROG/P, FUGR/F, TABL/DT, DDLS/DF. Defaults to CLAS/OC.
`onlyCustom`	No	Keep only Z, Y and /namespace/ objects (default true). The count of standard objects left out is reported.
`packageName`	No	Only usages in this package.
`includeTests`	No	Include usages that are only in test includes (default true); they are marked testOnly either way.
`maxPlacesPerObject`	No	How many places to list per object. Default 8; the rest are counted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Sep 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description reveals substantial behavioral details beyond the read-only annotations: standard SAP objects are excluded unless asked for, test usages are marked, depth=2 changes traversal, and an empty answer is explicitly ambiguously possible due to dynamic-only callers. It also warns about response size, helping agents anticipate huge results. This is genuinely useful safety and interpretation guidance.

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?

The description is a single dense paragraph with no fluff and it front-loads the core purpose. The sentence about output size and dynamic-caller ambiguity is valuable but makes it longer than strictly necessary. It is efficient and purposeful, though not as tightly structured as a two-sentence ideal.

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

Completeness4/5

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

For a tool with 11 parameters, no output schema, and only read-only annotations, the description covers the important non-obvious details: result shape, package/object/member tree, test handling, standard-object filtering, depth semantics, and the empty-result caveat. It doesn't specify exact response field names, but it gives enough high-level grounding for an agent to use the tool correctly.

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 all eleven parameters already carry individual descriptions. The tool description adds some high-level semantics such as depth following callers and standard-object filtering, but it mostly justifies that already documented. Baseline 3 is appropriate because 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?

The description opens with a clear statement of what the tool computes: 'What depends on an object, or on one method of it,' naming objects, places, and packages. It also distinguishes itself from usageReferences by positioning this tool as a rolled-up, readable alternative, which separates it from the closely related sibling.

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

Usage Guidelines4/5

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

It gives useful context about when this tool is appropriate by comparing it to usageReferences: this is the readable summary when the raw tree would be enormous. There is no explicit when-not-to-use list, but the intended usage slot is clear. It does not address all nearby siblings such as whereUsedMethod or usageReferenceSnippets, so it falls just short of 5.

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

Deploy Server

impactOf

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools