Assess how far ABAP source is from ABAP Cloud (Clean Core tier 1) by parsing it twice — once at a classic baseline (default v758) and once at version Cloud — and diffing: findings that appear only at Cloud are genuine cloud blockers (statements ABAP Cloud removed), reported in categories (dynpro, list output, native SQL, report events, …) with a transparent score, an A–D tech-debt grade and a verdict; findings already present at the baseline are reported separately as broken code, not migration work. Use this when someone asks 'is this code cloud-ready / Clean Core compliant / S/4HANA-cloud safe', before porting classic ABAP into an ABAP Cloud environment, or for a graded tech-debt assessment of an abapGit export. It is static and parser-level: it does not check released-API usage (that needs a system's ATC), does not connect to any SAP system, and a 'ready' verdict means no language-level blockers — not a certification. Example: check_cloud_readiness({ "files": [ { "source": "REPORT zold.\nWRITE: / 'hi'." } ] }).

Look up ABAP repository objects (DB tables, CDS view entities, function modules, classes, interfaces, …) in SAP's published ABAP Cloudification list and report, per object, whether it is a 'released' API (safe to use in ABAP Cloud / Clean Core), 'deprecated' (released but being retired), or 'not-released' (a classic/internal object that is not a public API — e.g. most classic DDIC tables) — with a curated CDS successor hint for common tables. This reflects SAP's official Cloudification list as bundled in this package (snapshot 2026-06-10); it ships offline with the server. Use this when you need to know if your code may reference a given object in ABAP Cloud, or which released CDS view to use instead of a classic table — the released-API half of readiness that check_cloud_readiness deliberately leaves to a system's ATC. It does not connect to any SAP system, does not run ATC, and is only as current as the bundled snapshot — a system's own released-API list (ATC check API_RELEASE_STATE_CHECK / SAP_CP_READINESS) remains authoritative; treat an 'absent from the list' result as 'not-released as of the snapshot', not as proof. Example: check_released_api({ "objects": ["MARA", "I_Product", "BAPI_MATERIAL_GET_DETAIL"] }).

Compare a BEFORE and an AFTER version of ABAP source and report what a rework actually changed: lint findings resolved and introduced (matched by content, so moved-but-unchanged code is not noise), cloud-blocker / score / A–D grade movement from the same dual-parse diff as check_cloud_readiness, and structural changes — classes, methods and FORMs added or removed. Use this when reviewing a refactor, a modernization step or an AI-generated rewrite of an existing object and you need an objective better-or-worse verdict instead of eyeballing a diff. It is not a textual diff tool (use git diff to see the edits) and it cannot judge functional equivalence — behavior can change while every number improves; it does not connect to any SAP system. Example: compare_abap({ "before": [ { "source": "REPORT zr.\nWRITE 1." } ], "after": [ { "source": "REPORT zr.\nWRITE 2." } ] }).

Explain one abaplint rule in depth: title, description, extended rationale (often citing the Clean ABAP style guide), tags, documentation URL, and good/bad code examples where the rule defines them. Use this when a lint_abap or check_cloud_readiness finding needs justification — to explain to a developer why the finding matters and how to fix it. It does not run analysis and only knows abaplint rules; SAP ATC check documentation is out of scope. Example: explain_abap_rule({ "rule": "exit_or_check" }).

Pretty-print one ABAP source: normalize keyword casing and indentation using abaplint's formatter — the offline equivalent of Pretty Printer in ADT/SE80. Use this when generated or hand-written ABAP has inconsistent casing/indentation and you want it normalized before review or commit. It does not reformat CDS views or behavior definitions, does not change any logic, and fails cleanly on source it cannot parse. Example: format_abap({ "source": "report ztest.\nwrite 'hi'." }).

Return the structural outline of ABAP sources — classes (with methods, visibility, attributes, interfaces, inheritance), interfaces, and FORM routines — without you having to read the whole file. Use this when navigating a large class or legacy program to decide which part to read or edit next; it is the cheap first call before pulling thousands of lines into context. Set mermaid: true to also get the structure as a Mermaid classDiagram (inheritance, interface realization, method visibility) for documentation visuals. It does not return method bodies or analyze code quality (use lint_abap for that), and CDS/behavior-definition files yield an empty outline. Example: get_abap_outline({ "files": [ { "filename": "zcl_big.clas.abap", "source": "CLASS zcl_big DEFINITION…" } ] }).

Run abaplint static analysis over ABAP, CDS or behavior-definition sources and return structured findings (rule key, message, severity, file/line/column, the offending line, and a docs URL per finding). Use this when you have written or modified ABAP code and want style and correctness feedback before it goes anywhere near a system — it runs entirely offline on the provided text. It does not connect to any SAP system, does not run ATC, and cannot judge whether referenced objects exist unless you provide them in the same call (preset "style", the default, skips whole-program checks for that reason; preset "full" enables them when you provide every dependency). A focus tag turns a pass into a themed review (performance / security / Clean ABAP style) without hand-picking rules; rule overrides layer a team's own pack on top. For an ABAP-Cloud migration verdict use check_cloud_readiness instead. Example: lint_abap({ "files": [ { "source": "REPORT ztest.\nDATA foo TYPE i.\nIF foo = 1.\nENDIF." } ] }).

List the abaplint rules this server can check, optionally filtered by a free-text query or a tag, returning key, title, one-line description, tags and a documentation URL per rule. Use this when deciding which rules to enable or override in lint_abap, or to discover what a Clean-ABAP-style check exists for. It does not run any analysis and does not change configuration — it is a read-only catalog. Example: list_abap_rules({ "query": "obsolete" }).

Generate the complete, canonical RAP managed business-object stack for one root entity: root CDS view entity, behavior definition (managed, strict(2), optional draft), behavior implementation class with handler locals, projection view with transactional_query, projection behavior definition, UI metadata extension, and an OData V4 service definition — plus a suggested table DDL, the activation order, and next steps. Use this when starting a new RAP business object in ABAP Cloud or S/4HANA and you want correct boilerplate that follows the SAP /DMO reference shape instead of writing it by hand. Generated classes and CDS views are round-trip validated through abaplint at ABAP-Cloud level before being returned; behavior and service definitions are canonical templates (abaplint does not parse those deeply) and ADT activation is the final check. It does not create the table or the service binding (binding is not a source artifact — create it in ADT), and it generates single-entity BOs: model compositions (parent-child) yourself for now. Example: scaffold_rap_bo({ "entityName": "Travel", "sqlTable": "ztravel", "keyField": "travel_id", "fields": [ { "name": "agency_id", "type": "abap.char(6)" } ], "draft": true }).