Skip to main content
Glama
palimkarakshay

abap-mcp

by palimkarakshay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Lint ABAP source

lint_abap
Read-onlyIdempotent

Run abaplint static analysis on ABAP, CDS, or RAP behavior-definition sources offline to return rule, severity, and line-level findings before deployment.

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
NameRequiredDescriptionDefault
filesYesSource files to analyze, up to 32 per call, 100k chars each.
focusNoCurated 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.
rulesNoabaplint 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.
presetNo"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
rapCheckNoAlso 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).
abapVersionNoABAP language version to parse against. "v758" (default) is current on-prem; "Cloud" is ABAP Cloud / Steampunk.v758

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
findingsYes
fileCountYesNumber of files analyzed.
truncatedYesTrue if the list was cut short — more than 500 findings, or the RAP checker hit one of its own caps.
rapCheckedYesTrue when the RAP checker ran (the call held a BDEF/SRVD and rapCheck was on); its findings carry rap/ rule keys.
rapScopeNoteNoPresent only when rapChecked is true: what the RAP checker proves and does not prove.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.4
    • addedInput schema / properties / rules / additionalProperties / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  }
+]
  2. Changed5 schema fields changedv0.12.0
    • 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"
+]
  3. First observedv0.4.5

TDQS

A4.8/5.0
Behavior5/5

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

Although annotations already declare readOnly/openWorld/idempotent, the description adds substantial behavioral context they cannot convey: fully offline execution, no SAP connection, the limits on referenced-object validation, and the silent-RAP-gap explanation with the rapCheck opt-out. This is the kind of disclosure that prevents an agent from mis-trusting an empty result.

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?

Front-loaded with purpose and output shape, and every clause carries information. However it reads as a dense run-on with heavy parenthetical nesting, so the density slightly impedes scanning even though little is wasted.

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?

For a 6-parameter tool with nested file objects and an output schema, the description covers the offline execution model, the RAP-merge side effect, preset/focus semantics, alternatives, and a concrete example call. Nothing needed to invoke it correctly is missing.

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 baseline is 3, but the description genuinely layers meaning: how a focus tag interacts with preset (ignored under syntax-only), how rules merge onto preset and focus, and why preset "style" skips whole-program checks. It goes beyond restating schema text rather than merely echoing it.

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?

Opens with a specific verb+resource: "Run abaplint static analysis over ABAP, CDS or behavior-definition sources" and immediately names the return shape. It explicitly distinguishes itself from siblings by routing cloud-migration verdicts to check_cloud_readiness and full RAP reports to check_rap_behavior.

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?

States the triggering condition ("when you have written or modified ABAP code and want style and correctness feedback") and gives explicit exclusions — no SAP connection, no ATC, no existence checks without dependencies. It also routes two adjacent scenarios to named alternatives and explains which preset/focus to pick for each.

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

Deploy Server

Other Tools