ARC-1

Read SAP ABAP objects. Types: PROG, CLAS, INTF, FUNC, FUGR (use expand_includes=true to get all include sources), INCL, DDLS, DDLX (CDS metadata extensions — UI annotations), BDEF, SRVD, SRVB (service bindings — returns structured binding info: OData version, publish status, service definition ref), TABL, VIEW, STRU (DDIC structures like BAPIRET2 — returns CDS-like source), DOMA (DDIC domains — returns type info, value table, fixed values), DTEL (data elements — returns domain, labels, search help), TRAN (transaction codes — returns description, program, package), TABLE_CONTENTS, DEVC, SOBJ (BOR business objects — returns method catalog or full implementation), SYSTEM, COMPONENTS, MESSAGES, TEXT_ELEMENTS, VARIANTS. For CLAS: omit include to get the full class source (definition + implementation combined). The include param is optional — use it only to read class-local sections: definitions (local types), implementations (local helper classes), macros, testclasses (ABAP Unit). For CLAS with method param: use method="*" to list all methods with signatures and visibility, or method="method_name" to read a single method implementation (95% fewer tokens than full source). For SOBJ: returns BOR method catalog; use method param to read a specific method implementation. BSP (deployed UI5/Fiori apps — list apps, browse files, read content; use name to browse app structure, include for subfolder or file), BSP_DEPLOY (query deployed UI5 apps via ABAP Repository OData Service — returns name, package, description). API_STATE (API release state — checks if an object is released for ABAP Cloud / S/4HANA Clean Core; returns contract states C0-C4, successor info; use objectType param for non-class objects). INACTIVE_OBJECTS (list all objects pending activation — no name param needed; use before SAPActivate batch_activate to see what needs activating).

Search for ABAP objects. Search by name pattern with wildcards (* for any characters). Returns object type, name, package, description, and ADT URI. Use this to find classes, programs, function modules, tables, etc.

Tips: BOR business objects appear as SOBJ type in results. The uri field from results can be used directly with SAPNavigate for references. The objectType field in results maps to SAPRead's type parameter — drop the slash suffix (DDLS/DF → DDLS, CLAS/OC → CLAS, PROG/P → PROG).

Note: Searches object names only (classes, tables, CDS views, etc.) — field/column names are not searchable here. To find fields by name, use SAPRead(type='DDLS', include='elements') for CDS views or SAPQuery against DD03L.

Navigate code: find definitions, references (where-used), code completion, and class hierarchy. Use for "go to definition", "where is this used?", "what does this class inherit?", and auto-complete. For references: uses the full scope-based Where-Used API returning detailed results with line numbers, snippets, and package info. Optional objectType filter narrows results to a specific ADT type in slash format (e.g., CLAS/OC, PROG/P). For hierarchy: returns superclass, implemented interfaces, and direct subclasses via SEOMETAREL. You can use type+name instead of uri (e.g., type="CLAS", name="ZCL_ORDER") for a where-used list without needing the full ADT URI.

Run local abaplint rules on ABAP source code. System-aware: auto-selects cloud or on-prem rules based on detected system type.

Actions:

• "lint": Check ABAP source for issues. Returns errors and warnings.

• "lint_and_fix": Lint + auto-fix all fixable issues (keyword case, obsolete statements, etc.). Returns fixed source.

• "list_rules": List all available rules with current config. No source needed.

For server-side checks (ATC, syntax check, unit tests), use SAPDiagnose instead.

Run diagnostics on ABAP objects and analyze runtime errors.

Actions:

• "syntax": Syntax check an ABAP object. Requires name + type.

• "unittest": Run ABAP unit tests. Requires name + type.

• "atc": Run ATC code quality checks. Requires name + type. Optional: variant.

• "dumps": List or read ABAP short dumps (ST22). Without id: lists recent dumps (filter by user, maxResults). With id: returns full dump detail including formatted text, error analysis, source code extract, and call stack.

• "traces": List or analyze ABAP profiler traces. Without id: lists trace files. With id + analysis: returns trace analysis (hitlist = hot spots, statements = call tree, dbAccesses = database access statistics).

Get compressed dependency context for an ABAP object or CDS entity. 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. This is the most token-efficient way to understand dependencies. Instead of N separate SAPRead calls returning full source (~200 lines each), SAPContext returns ONE response with compressed contracts (~15-30 lines each). Typical compression: 7-30x fewer tokens.

What gets extracted 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: SAP standard objects (CL_ABAP_, IF_ABAP_, CX_SY_) are excluded — the LLM already knows standard SAP APIs. 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 CDS analysis: Use SAPContext instead of reading each view in the dependency chain individually. A single SAPContext call on a consumption view (e.g., ZC_*) returns all dependent interface views, tables, and associations — replacing 5-10 separate SAPRead calls. Only use targeted SAPRead for metadata extensions (DDLX) or service bindings (SRVB) that SAPContext does not cover.