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. When the call contains a .bdef.asbdef or .srvd.srvdsrv file, abap-mcp's own RAP checker also runs over the whole set and its findings are merged in under rap/ rule keys (abaplint does not deep-parse those file types, so without this they would silently produce nothing); set rapCheck:false to opt out, or call check_rap_behavior for the full structured RAP report with hints, confidence and the scope note. 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. Our A–D grade is blocker density (see gradeMeaning), NOT SAP's own Clean Core Level A–D; a target system's own released-API ATC check ("Usage of Released APIs (Cloudification Repository)" for SAP Cloud ERP Public Edition / "Usage of APIs (Cloudification Repository)" for SAP Cloud ERP Private Edition / on-premise, via variants such as ABAP_CLEAN_CORE_DEVELOPMENT / ABAP_CLEAN_CORE_READINESS) 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 SAP's own successor(s) when the snapshot has any, a curated CDS successor hint otherwise, and a classicAPI/noAPI/internalAPI classification where SAP publishes one. This reflects SAP's official per-edition Cloudification lists as bundled in this package (default edition "s4hc", snapshot 2026-09-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. 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 target system's own released-API ATC check ("Usage of Released APIs (Cloudification Repository)" for SAP Cloud ERP Public Edition / "Usage of APIs (Cloudification Repository)" for SAP Cloud ERP Private Edition / on-premise, via variants such as ABAP_CLEAN_CORE_DEVELOPMENT / ABAP_CLEAN_CORE_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…" } ] }).

Look up what changed in ABAP Cloud, CDS, ABAP SQL, RAP, EML, ABAP Unit, ATC and the development tools across the 2502 to 2608 release trains plus ABAP Platform 2025 (SAP_BASIS 816), from a dated knowledge base bundled with this package. Each row carries an original summary, an optional syntax sketch, the release and ABAP release, the products it was verified for, the cited SAP source URL, and a confidence flag ("confirmed" = fact-checked, "reported" = single-source). Use this when you are about to write or review ABAP and need to know whether a language, CDS or RAP feature exists in the target release — for example before using CDS table entities as draft persistence, BUFFER ON, RAP change documents, global side effects, or a feature-control attribute. Filter by sinceRelease to see only what is new since the customer's current level. Rows flagged pre-2502 exist to stop an agent presenting an established feature (business events, late numbering, prechecks, bgPF) as a 2025-26 novelty. It does not connect to any SAP system, does not read release notes live, and is not a complete changelog — it is a curated snapshot (curated 2026-09-10) and the target system's own release notes stay authoritative. For released-API state of a specific object use check_released_api; for Clean Core levels and ATC vocabulary use search_sap_knowledge. Example: explain_abap_release({ "sinceRelease": "2605", "kind": "rap" }).

Search one dated, cited knowledge bundle covering three areas: ABAP Cloud / RAP release deltas, Clean Core governance (SAP's extensibility Levels A-D, release contracts C0 to C4, the real ATC check and variant names, and the SAP/abap-atc-cr-cv-s4hc Cloudification Repository file and schema inventory), and decision cards for the SAP AI options an ABAP team can reach (SAP-ABAP-1, the Generative AI Hub orchestration API, the ABAP AI SDK powered by ISLM, Joule for Developers, SAP's official ADT MCP server, the custom code migration agent, and the community MCP ecosystem). Every hit returns its sources, a confidence flag and the full card. Use this when a question is about SAP facts rather than about a piece of source text — which Clean Core level a pattern lands in, what a C1 release contract guarantees, which ATC variant to run, whether SAP-ABAP-1 accepts a system prompt, which classes the ABAP AI SDK exposes, or what SAP's own MCP server can and cannot do. It does not connect to any SAP system, does not run ATC, does not fetch anything live, and is not a substitute for a real ATC run or for SAP's own documentation — it is a curated snapshot (curated 2026-09-10) and the target system and SAP's current documentation stay authoritative. For release-timeline questions prefer explain_abap_release; for the release state of a specific object use check_released_api; to analyze actual source text use lint_abap or check_cloud_readiness. Example: search_sap_knowledge({ "query": "sap-abap-1 system prompt" }).

Generate one validated global ABAP class that calls the SAP Generative AI Hub through the ABAP AI SDK powered by Intelligent Scenario Lifecycle Management (ISLM) — SAP's own client library, not a third-party SDK with a similar name. Seven interaction shapes: "string" (single prompt via EXECUTE_FOR_STRING), "messages" (system/user/assistant turns plus token-count/finish-reason retrieval), "prompt-template" (CL_AIC_ISLM_PROMPT_TPL_FACTORY, never the non-existent CL_AIC_PROMPT_TEMPLATE), "function-calling" (the tool-call DO-loop, with the upstream SAP sample's undeclared-tool_calls bug fixed — the table is declared and populated before ADD_TOOL_RESULTS), "structured-output" (DEFINE_RESPONSE_FORMAT->JSON_SCHEMA->FROM_STRING), "streaming" (IF_AIC_ADT_COMPLETION_API delta loop), and "orchestration" (the separate Orchestration API, which does not yet support structured output, function calling or media input). Every generated class carries an injectable constructor seam (an OPTIONAL api parameter) so it can be unit-tested with cl_abap_testdouble instead of a live ISLM scenario; pass withUnitTest for a FOR TESTING skeleton using that seam. Generated files are round-tripped through abaplint (version Cloud, preset syntax-only) together with abap-mcp's own bundled stub declarations of the referenced IF_AIC_*/CL_AIC_*/CX_AIC_* types, labelled validated:"abaplint-syntax" — this proves the ABAP parses, not that it matches SAP's real API surface exactly. Use this when you are adding a Generative-AI-Hub call to ABAP Cloud code and want correct, cited API shapes instead of guessing class/method names from memory (a common LLM hallucination surface — e.g. inventing CL_AIC_PROMPT_TEMPLATE, or copying SAP's own buggy function-calling sample verbatim). It does NOT call any LLM, does NOT deploy or activate anything, and does NOT create the SAP_COM_0A69 communication arrangement or the Intelligent Scenario (INTS/INTM) itself — those are manual ISLM/BTP-cockpit steps returned in setupSteps that this tool has no way to perform (no SAP system, no credentials, no network). Example: scaffold_abap_ai_sdk({ "scenarioName": "ZDEMO_AI_SCENARIO", "interaction": "string" }).

Generate the ABAP section of a repository's AGENTS.md / CLAUDE.md: the lint-before-commit rule, the ABAP Cloud readiness gate, released-API discipline, scaffold-first, the offline unit-test loop, and the division of labour with an online ADT MCP server. Use this when you set up a new ABAP repo for agentic development or want a team's coding-agent rules to reference the abap-mcp tools consistently. It does not write the file (paste the returned markdown yourself), does not read the workspace, and is not a substitute for the project's own conventions — it encodes the tool contract, nothing project-specific beyond the parameters you pass. Example: { "target": "Cloud", "pairedWith": ["sap-adt-mcp"], "runEnabled": true }.

Check RAP behavior definitions (.bdef.asbdef) and CDS service definitions (.srvd.srvdsrv) for syntax and structural-consistency defects, offline, using abap-mcp's own BDL/SDL parser — abaplint does not deep-parse either file type (it stores a BDEF behind a single regex and a SRVD not at all), so this is the only static feedback these files get without a system. Reports the draft/etag/lock/authorization/numbering consistency set, strict-mode obligations, action/operation/validation/determination/side-effect coherence, projection 'use' statements against the base BDEF, and service 'expose' sets against the CDS entities you pass in the same call; with abapRelease set, it also flags constructs newer than that release from a bundled, dated copy of SAP's RAP BDL feature table. Use this when you have written or generated a BDEF/SRVD (by hand, from scaffold_rap_bo, or from a model that may have invented RAP syntax) and want it checked before it reaches ADT — and pass the base BDEF and the .ddls.asddls views alongside it, because the cross-file rules only run on files present in the call. It does NOT connect to SAP, does not activate anything, does not run ATC, cannot see DDIC tables, behavior-pool classes or CDS field types, and cannot certify that ADT would accept the file — the grammar is derived from SAP's published feature tables plus a 102-file corpus of Apache-2.0 SAP sample sources, so constructs it does not recognise are reported as info, never as errors. For ABAP classes use lint_abap; for a new BO use scaffold_rap_bo; for what a release added use explain_abap_release. Example: check_rap_behavior({ "files": [ { "filename": "zr_travel.bdef.asbdef", "source": "managed implementation in class zbp_travel unique;\nstrict ( 2 );\nwith draft;\n\ndefine behavior for ZR_Travel alias Travel\npersistent table ztravel\nlock master\n{ create; }\n" } ], "abapRelease": "2508" }).