Skip to main content
Glama

Check a RAP behavior/service definition

check_rap_behavior
Read-onlyIdempotent

Validate RAP behavior definitions (.bdef.asbdef) and CDS service definitions (.srvd.srvdsrv) for syntax and structural consistency offline before they reach ADT.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesThe BDEF/SRVD files to check, plus any .ddls.asddls or base .bdef.asbdef you want cross-checked in the same call. Up to 32 files, 100k chars each — passing the base BDEF and the CDS views is what turns on the cross-file half of the rule set.
strictNoRun the strict-mode rules even when the BDEF does not declare strict/strict(2) — use it to see what a BO would have to fix before it can be released under the C0/C1 contract. Default false: strict rules run only on BDEFs that declare strict.
abapReleaseNoTarget ABAP Cloud release, e.g. "2508". When set, constructs whose SAP-documented minimum release is newer are reported as warnings (rule RAP900) from the bundled, dated feature table. Omit to skip release gating.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesOne row per supplied file: what it was taken to be, and whether it parsed.
summaryYesCounts, including the two honesty counters that make coverage gaps measurable.
findingsYesEvery rule finding, sorted by file, line, column, rule id.
scopeNoteYesExactly what this checker proves and does not prove — abaplint did not parse these files, and ADT remains the authority.
validatedYesChecked by abap-mcp's own RAP parser + rule set at the stamped grammar/rules version. It does NOT claim abaplint parsed it, that SAP's parser would accept it, or that the object would activate.
releaseGateNoPresent only when abapRelease was passed.
rulesVersionYesWhich rule set judged them, e.g. "rap-rules/1.0.0".
grammarVersionYesWhich BDL/SDL grammar read the files, e.g. "bdl/2026-09-10".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld=false/idempotent, and the description adds substantial context beyond them: strictly offline, no SAP connection, no activation, no ATC, cannot see DDIC tables or pool classes, and the important caveat that unknown constructs are reported as info, never errors, because the grammar is corpus-derived.

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-loads the purpose before usage, limits, siblings and example, and every clause carries information. It is dense and long for a single block of prose, but not padded with filler.

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?

With an output schema present, return values need not be described; the description covers scope, offline limits, cross-file prerequisites, release gating, sibling routing and an example, which is complete for a self-contained static checker.

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; the description earns more by explaining the semantics of passing base BDEF and .ddls.asddls files (this is what activates the cross-file half of the rules) and what abapRelease gating does, with a worked example call.

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 (check) and resource (RAP behavior definitions .bdef.asbdef and CDS service definitions .srvd.srvdsrv), plus the defect classes it looks for. It explicitly distinguishes itself from abaplint and from sibling tools, so an agent can route to it without opening the schema.

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 generated a BDEF/SRVD ... before it reaches ADT') and names the alternatives with their selection condition (lint_abap for classes, scaffold_rap_bo for new BOs, explain_abap_release for release history). It also states the required companion files (base BDEF, .ddls.asddls) that enable cross-file rules.

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