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." } ] }).

Apply abaplint's own machine-applicable corrections to ABAP sources and return the corrected code: keyword casing, obsolete statements with defined modern replacements (MOVE → =, and every other rule that ships a concrete edit), applied in verified batches — after each batch the result is re-parsed, and a batch that would break the parse is discarded, so the output is parser-guaranteed, never guessed. Findings WITHOUT a machine fix come back in remaining — those need judgment (yours or an agent's, proven afterwards with compare_abap). Use this when someone highlights code and wants it corrected to best practices / modern syntax instantly, as the mechanical first pass before any AI rewriting, or to modernize a file before review. It does not invent rewrites (only fixes abaplint defines), does not resolve cloud blockers that need re-architecture (dynpro, WRITE output — see plan_cloud_migration), and is not a formatter (format_abap pretty-prints without changing statements). Example: fix_abap({ "files": [ { "source": "report zdemo.\ndata lv_x type i.\nmove 5 to lv_x." } ] }).

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. It also reports snapshot-dated released-API observations for direct table and function-module references the parser can extract; those stay separate from the language-level blocker count and score. 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: its released-API scan is not exhaustive dependency discovery, it does not connect to any SAP system or run ATC, and a 'ready' verdict means no detected language-level blockers — not a certification. A target system's ATC remains authoritative. Example: check_cloud_readiness({ "files": [ { "source": "REPORT zold.\nWRITE: / 'hi'." } ] }).

Turn ABAP sources into an ordered, phased ABAP Cloud migration backlog: runs the same dual-parse analysis as check_cloud_readiness, then arranges every blocker into per-object work items across consulting-ordered phases — repair-the-baseline first (broken code is not migration work), then mechanical quick wins, core rework of removed statements, UI/output re-architecture, and a separate snapshot-dated released-API remediation phase. Each work item carries an S/M/L effort band, a remediation recipe and sample locations; each phase carries a goal and objective, re-checkable exit criteria. Use this when someone asks 'plan the migration', 'what do we tackle first', or wants a work breakdown / task backlog instead of raw findings — the natural next call after check_cloud_readiness says rework is needed. It is a deterministic re-arrangement of the readiness analysis: it does not estimate person-days, does not modify any code, and inherits every readiness limitation (static, parser-level, snapshot-dated released-API data — a system's ATC stays authoritative). Example: plan_cloud_migration({ "files": [ { "source": "REPORT zold.\nWRITE: / 'hi'.\nCALL SCREEN 100." } ] }).

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." } ] }).

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 }).

Generate the local ABAP Unit test-class include (.clas.testclasses.abap) for each global class in the provided sources: a FOR TESTING class (RISK LEVEL HARMLESS, DURATION SHORT) with a setup method that instantiates the class under test and one skeleton test method per public method. Every skeleton fails loudly with cl_abap_unit_assert=>fail('TODO …') so generated-but-empty tests can never masquerade as coverage; abstract classes and parameterized constructors get TODO guidance instead of a blind NEW #( ). Generated code is round-tripped through abaplint together with the class under test before being returned. Use this when a class has no tests yet and you want a correct, ready-to-fill test harness — the natural first step of test-driven rework and the 'add tests before we migrate this' consulting task. It does not invent assertions or test data (the given/when/then substance is yours or the agent's to write), does not create test doubles, and cannot run the tests — ADT/CI does that. Example: scaffold_abap_unit({ "files": [ { "filename": "zcl_travel.clas.abap", "source": "CLASS zcl_travel DEFINITION PUBLIC.\n…" } ] }).

Build a dependency graph over the provided ABAP sources for migration sequencing and impact reading: nodes are the provided objects plus every DB table / function module they reference (annotated with released-API state and CDS successor from the bundled SAP snapshot); edges are tiered by how they were derived — parser-level db-access and call-function references, structural inherits/implements from class definitions, and word-boundary references-textual matches between the provided objects. Optional Mermaid flowchart output. Use this when deciding what to migrate first (leaves before roots), what a rework might break, or which objects pull non-released tables into the picture — the sequencing companion to plan_cloud_migration. It is not a system where-used list: it only sees the text you pass, textual edges cannot see dynamic calls, and an absent edge is not proof of independence — a system's where-used and ATC remain authoritative. Example: get_object_dependencies({ "files": [ { "filename": "zcl_a.clas.abap", "source": "…" }, { "filename": "zcl_b.clas.abap", "source": "…" } ], "mermaid": true }).

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-08-24); 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. This explicit lookup complements check_cloud_readiness's limited, source-extracted released-API observations and can check objects that do not appear in the supplied source. 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"] }).

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" }).

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…" } ] }).