abap-mcp

Overview Schema Source Related Servers Discussions Admin

Lint ABAP source

lint_abap

Read-onlyIdempotent

Run abaplint static analysis on ABAP, CDS, or behavior-definition code to catch style and correctness issues offline before the code reaches SAP.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`files`	Yes	Source files to analyze, up to 32 per call, 100k chars each.
`focus`	No	Curated rule-pack lens: report only rules carrying this abaplint tag — "Performance" for a tuning pass, "Security" for a security sweep, "Styleguide" for Clean ABAP adherence. Parser errors always surface. Ignored with preset "syntax-only". Combine with rules to re-tune individual rules in the pack.
`rules`	No	abaplint rule overrides merged onto the preset (and onto a focus filter), e.g. { "line_length": { "length": 120 }, "7bit_ascii": false } — encode an org's best-practice pack here.
`preset`	No	"style" (default): abaplint default rules minus whole-program semantic checks — right for isolated snippets. "full": every default rule, expects all referenced objects provided. "syntax-only": parser errors only.	style
`rapCheck`	No	Also run abap-mcp's own RAP behavior/service-definition checker when the call contains a .bdef.asbdef or .srvd.srvdsrv file, merging its findings under namespaced "rap/RAP026"-style rule keys. Default true — abaplint returns nothing at all for those file types. Set false for abaplint-only output (e.g. a CI that compares finding counts across versions).
`abapVersion`	No	ABAP language version to parse against. "v758" (default) is current on-prem; "Cloud" is ABAP Cloud / Steampunk.	v758

Output Schema

TableJSON Schema

Name	Required	Description
`findings`	Yes
`fileCount`	Yes	Number of files analyzed.
`truncated`	Yes	True if the list was cut short — more than 500 findings, or the RAP checker hit one of its own caps.
`rapChecked`	Yes	True when the RAP checker ran (the call held a BDEF/SRVD and rapCheck was on); its findings carry rap/ rule keys.
`rapScopeNote`	No	Present only when rapChecked is true: what the RAP checker proves and does not prove.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.12.0Sep 12, 2026

addedInput schema / properties / rapCheck

Added value: +{
+  "default": true,
+  "description": "Also run abap-mcp's own RAP behavior/service-definition checker when the call contains a .bdef.asbdef or .srvd.srvdsrv file, merging its findings under namespaced \"rap/RAP026\"-style rule keys. Default true — abaplint returns nothing at all for those file types. Set false for abaplint-only output (e.g. a CI that compares finding counts across versions).",
+  "type": "boolean"
+}

addedOutput schema / properties / rapChecked

Added value: +{
+  "description": "True when the RAP checker ran (the call held a BDEF/SRVD and rapCheck was on); its findings carry rap/ rule keys.",
+  "type": "boolean"
+}

addedOutput schema / properties / rapScopeNote

Added value: +{
+  "description": "Present only when rapChecked is true: what the RAP checker proves and does not prove.",
+  "type": "string"
+}

changedOutput schema / properties / truncated / description

Previous value: -"True if more than 500 findings existed and the list was cut."New value: +"True if the list was cut short — more than 500 findings, or the RAP checker hit one of its own caps."

changedOutput schema / required

Previous value: -[
-  "findings",
-  "truncated",
-  "fileCount"
-]New value: +[
+  "findings",
+  "truncated",
+  "fileCount",
+  "rapChecked"
+]

First observedv0.4.5Jul 7, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/idempotent/closed-world annotations: it discloses offline execution, no SAP system connection, no ATC, inability to resolve referenced objects, the semantic-check gap of the default preset, and the automatic RAP-check merge for .bdef/.srvd files with an opt-out. These are non-obvious behavioral traits an agent needs.

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?

Purpose and return shape are front-loaded, and most sentences carry unique information. However, it is a dense single-block wall of text mixing purpose, constraints, presets, focus, overrides, and RAP handling, which could be better partitioned for scanning.

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?

An output schema exists, so return structure needn't be re-explained, yet the description still summarizes findings. For a six-parameter tool with nested file objects it covers triggers, alternatives, preset trade-offs, the RAP merge edge case, and an example call, leaving no material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all six parameters, setting a baseline of 3. The description adds real meaning on top: why preset "style" is the default, that focus is ignored under "syntax-only", how rule overrides layer onto presets and focus, and why rapCheck defaults true.

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?

States a specific verb+resource (run abaplint static analysis over ABAP/CDS/behavior-definition sources) and what it returns (rule key, message, severity, file/line/column, offending line, docs URL). It explicitly distinguishes itself from siblings by naming check_cloud_readiness and check_rap_behavior and clarifying it is not ATC.

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?

Gives an explicit trigger ("when you have written or modified ABAP code and want style and correctness feedback before it goes anywhere near a system") and routes alternatives ("For an ABAP-Cloud migration verdict use check_cloud_readiness instead"; "call check_rap_behavior for the full structured RAP report"). It also explains when each preset applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server