Skip to main content
Glama

SAPContext

Provides compressed dependency context or CDS blast-radius impact for ABAP/CDS objects. Choose impact analysis to find what breaks when changing a CDS view, or deps to understand dependencies before editing.

Instructions

Get compressed dependency context or CDS blast-radius impact for an ABAP / CDS object.

Decision rule — pick the action based on the user's question:

  • "What breaks if I change ?" / "Who consumes <I_*>?" / "Impact analysis on " / "Blast radius" → action="impact"

  • "Understand dependencies before editing " / "What does X depend on?" → action="deps" (default)

  • "Find all callers of " (cache-warmup required) → action="usages"

action="impact" (CDS blast-radius, DDLS only): ALWAYS use this for CDS change-impact questions. Returns upstream AST dependencies plus downstream where-used results classified into RAP-aware buckets: projectionViews, bdefs, serviceDefinitions, serviceBindings, accessControls (DCLS), metadataExtensions (DDLX), abapConsumers, documentation (SKTD), tables, other. Also emits additive sibling-consistency diagnostics (consistencyHints + siblingExtensionAnalysis) when sibling DDLS variants in the same package show asymmetric metadata-extension coverage. DO NOT replicate this with SAPQuery against DDDDLSRC/ACMDCLSRC/DDLXSRC_SRC/SRVDSRC_SRC — those text scans produce noise (non-dependency matches, package group nodes) that this classifier already filters out. Optional includeIndirect=true widens to transitive consumers. Optional siblingCheck=false disables sibling analysis; siblingMaxCandidates controls fan-out (default 4, hard cap 10).

action="deps" (default): Returns only the public API contracts (method signatures, interface definitions, type declarations) of all objects that the target depends on — NOT the full source code. The most token-efficient way to understand dependencies. Instead of N separate SAPRead calls returning full source (~200 lines each), returns ONE response with compressed contracts (~15-30 lines each). Typical compression: 7-30x fewer tokens.

What deps extracts per dependency:

  • Classes: CLASS DEFINITION with PUBLIC SECTION only (methods, types, constants). PROTECTED, PRIVATE and IMPLEMENTATION stripped.

  • Interfaces: Full interface definition (interfaces are already public contracts).

  • Function modules: FUNCTION signature block only (IMPORTING/EXPORTING parameters).

  • CDS views (DDLS): All data sources (tables, other CDS views), association targets, and compositions. Each dependency's full source is included (table definitions, CDS DDL). Essential for CDS unit test generation — provides the dependency graph and field catalogs needed for cl_cds_test_environment doubles.

Filtering (deps): SAP standard objects (CL_ABAP_, IF_ABAP_, CX_SY_) are excluded. Custom objects (Z, Y*) are prioritized.

Use SAPContext BEFORE writing code that modifies or extends existing objects. Use SAPRead to get the full source of the target object, then SAPContext to understand its dependencies.

For non-CDS reverse-lookup, use SAPNavigate(action="references"). For CDS reverse-lookup, ALWAYS prefer action="impact" over SAPNavigate — it returns the same where-used data pre-classified into RAP buckets.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoAction: "impact" = CDS blast-radius analysis (DDLS only). USE THIS for any question like "what breaks if I change <view>", "who consumes <I_*>", "impact analysis on <CDS>", "downstream of <view>". Returns upstream AST dependencies + downstream where-used classified into RAP buckets (projectionViews, bdefs, serviceDefinitions, serviceBindings, accessControls, metadataExtensions, abapConsumers, documentation, tables, other), plus additive sibling-consistency diagnostics (consistencyHints + siblingExtensionAnalysis) when related DDLS siblings show asymmetric DDLX coverage. ALWAYS prefer over SAPQuery against DDDDLSRC/ACMDCLSRC/DDLXSRC_SRC/SRVDSRC_SRC (those text-scans produce noise this classifier filters out). Non-DDLS input returns a guardrail error. "deps" (default, can be omitted) = forward dependency context — "what does <object> depend on?". Returns public API contracts of dependencies. "usages" = reverse dependency lookup — "who calls <object>?". Requires cache warmup (--cache-warmup). Only "name" is needed. For CDS entities prefer action="impact" instead.
typeNoObject type. Required for action="deps" and action="usages". Optional for action="impact" — defaults to DDLS (the only supported type for impact).
nameYesObject name (e.g., ZCL_ORDER)
sourceNoOptional: provide source directly instead of fetching from SAP. Saves one round-trip if you already have the source from SAPRead.
groupNoRequired for FUNC type. The function group containing the function module.
maxDepsNoMaximum dependencies to resolve (default 20). Lower = faster + fewer tokens.
depthNoDependency depth: 1 = direct deps only (default), 2 = deps of deps, 3 = maximum. Higher depth = more context but more SAP calls.
includeIndirectNoOnly for action="impact". Include indirect (transitive) downstream where-used entries. Default false.
siblingCheckNoOnly for action="impact". Enable sibling metadata-extension consistency analysis. Default true.
siblingMaxCandidatesNoOnly for action="impact". Maximum sibling DDLS candidates to compare. Default 4; hard cap 10.
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: details on what each action returns (e.g., impact returns RAP-bucket classification, deps returns public API contracts), filtering (excludes SAP standard objects), token compression ratio (7-30x), cache requirement for usages, guardrail error for non-DDLS input, and effects of optional parameters.

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 well-structured with bullet points and clear sections, front-loading the purpose and decision rule. While lengthy, every sentence adds value for a complex tool. Minor redundancy could be trimmed, but overall effective.

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?

Given the tool's complexity (10 parameters, 2 enums, no output schema), the description covers error cases (guardrail for non-DDLS), cache requirements, default values, and behavior for different object types. It also relates to sibling tools, providing a complete picture for correct invocation.

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

Parameters5/5

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

The schema has 100% coverage, but the description adds significant value beyond parameter names and types. It explains default values (action defaults to deps), runtime behavior (e.g., siblingCheck default true, siblingMaxCandidates cap), and practical usage nuances (e.g., 'source' parameter saves a round-trip, 'group' required for FUNC).

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 clearly states the tool's purpose: 'Get compressed dependency context or CDS blast-radius impact for an ABAP / CDS object.' It distinguishes between three actions (impact, deps, usages) with explicit decision rules for each, and contrasts with sibling tools like SAPNavigate, SAPRead, and SAPSearch.

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?

The description provides explicit guidance on when to use this tool versus alternatives: 'Use SAPContext BEFORE writing code... Use SAPRead to get the full source... For non-CDS reverse-lookup, use SAPNavigate...' It also includes a detailed decision rule for selecting the appropriate action based on the user's question.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marianfoo/arc-1'

If you have feedback or need assistance with the MCP directory API, please join our Discord server