abap-mcp

Overview Schema Source Related Servers Discussions Admin

Scaffold a RAP business object

scaffold_rap_bo

Read-onlyIdempotent

Generates RAP managed business-object stack for one root entity: CDS view, behavior definition, implementation class, projection, UI metadata, service definition, table DDL, activation order.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`draft`	No	Generate draft handling (draft table reference, draft actions, use draft).
`fields`	No	Non-key business fields. Admin fields (created_by/created_at/…) are added automatically.
`prefix`	No	Customer namespace prefix for all generated names.	Z
`keyField`	Yes	snake_case key field of that table, e.g. "travel_id".
`sqlTable`	Yes	Persistent table the BO is backed by, e.g. "ztravel". Must start with the namespace prefix.
`entityName`	Yes	Entity name in UpperCamelCase, e.g. "Travel" — drives ZR_/ZC_/ZBP_/ZUI_ artifact names.
`managedUuidKey`	No	true (default): UUID key filled by managed numbering — modern RAP default. false: the caller provides the key on create.

Output Schema

TableJSON Schema

Name	Required	Description
`files`	Yes
`nextSteps`	Yes	What the generator cannot do for you (table, binding, draft table).
`rapFindings`	Yes	abap-mcp's own RAP checker findings on the generated BDEF/SRVD set — empty in normal operation.
`activationOrder`	Yes	The order to create/activate artifacts in ADT.
`validationIssues`	Yes	abaplint findings on the generated sources — empty in normal operation.
`suggestedTableDdl`	Yes	Starting-point DDL for the persistent table; adjust types.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.12.0Sep 12, 2026

changedOutput schema / properties / files / items / properties / validated / description

Previous value: -"\"abaplint\" = machine-parsed at Cloud level; \"template\" = golden-tested canonical template."New value: +"\"abaplint\" = machine-parsed at Cloud level; \"rap-checker\" = parsed and rule-checked by abap-mcp's own RAP BDL/SDL checker with zero error/warning findings; \"template\" = golden-tested canonical template only (the metadata extension — nothing machine-checks it)."

changedOutput schema / properties / files / items / properties / validated / enum

Previous value: -[
-  "abaplint",
-  "template"
-]New value: +[
+  "abaplint",
+  "template",
+  "rap-checker"
+]

addedOutput schema / properties / rapFindings

Added value: +{
+  "description": "abap-mcp's own RAP checker findings on the generated BDEF/SRVD set — empty in normal operation.",
+  "items": {},
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "files",
-  "activationOrder",
-  "nextSteps",
-  "suggestedTableDdl",
-  "validationIssues"
-]New value: +[
+  "files",
+  "activationOrder",
+  "nextSteps",
+  "suggestedTableDdl",
+  "validationIssues",
+  "rapFindings"
+]

First observedv0.4.5Jul 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: round-trip validation of classes and CDS views through abaplint at ABAP-Cloud level, while behavior/service definitions are canonical templates rather than deeply parsed, and ADT activation is the real final check. It also discloses the scoping limit (single-entity only) and the deferral of the service binding, which the readOnlyHint/idempotentHint annotations cannot convey.

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 the artifact list and the trigger condition, and the limitations and example follow in logical order. It is dense and lengthy, but every sentence (validation scope, deferred artifacts, single-entity restriction) earns its place.

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 7-parameter code-generation tool with an output schema already covering return values, the description supplies the trigger, the artifact inventory, validation guarantees, explicit non-goals, and a concrete example. Nothing an agent needs 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 adds a full worked example invocation that shows how entityName, sqlTable, keyField, fields, and draft combine in practice — meaningful semantics beyond the schema's field-by-field text.

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 precise verb (Generate) and resource (complete canonical RAP managed business-object stack for one root entity), then enumerates the exact artifacts produced. An agent can distinguish it from scaffold_abap_ai_sdk, scaffold_abap_unit, or check_rap_behavior without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the triggering scenario ('starting a new RAP business object in ABAP Cloud or S/4HANA') and sets boundaries — it does not create the table or service binding, and only handles single-entity BOs, with parent-child compositions left to the caller. It does not name a competing sibling tool by name, which is the only gap.

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

Deploy Server