Skip to main content
Glama

SAPContext

Read-only

Analyze CDS blast radius or dependency context for ABAP objects. Determine what breaks if you change a CDS view, or understand what an object depends on.

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?

Annotations declare readOnlyHint=true, consistent with the tool's read-only nature. The description adds extensive behavioral context: return structure for each action, token compression estimates, filtering of standard objects, guardrail errors, and sibling analysis details. No contradictions.

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 clear sections and bullet-like details, front-loading the main purpose. It is comprehensive but slightly verbose; some sentences could be trimmed. Overall, it earns its length for the complexity covered.

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?

Despite no output schema, the description fully covers all 10 parameters, specifies return formats for each action, explains edge cases (guardrails, cache), and provides usage guidance. It includes compression estimates and sibling analysis behavior, making it complete for an analysis tool.

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?

Schema coverage is 100%, and the description significantly enriches parameter meaning. For example, 'action' includes detailed usage rules and output specifications; 'includeIndirect', 'siblingCheck', and 'siblingMaxCandidates' are explained with their effects. This goes well beyond the schema definitions.

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 provides compressed dependency context or CDS blast-radius impact for ABAP/CDS objects. It distinguishes three specific actions (impact, deps, usages) with precise use cases, effectively differentiating from siblings like SAPRead, SAPNavigate, 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 decision rules for each action, including when to use (e.g., CDS change-impact) and when not to (e.g., avoid SAPQuery for CDS). It also covers prerequisites like cache warmup for 'usages' and gives alternatives for non-CDS scenarios.

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