Skip to main content
Glama

Scaffold an ABAP AI SDK (ISLM) class

scaffold_abap_ai_sdk
Read-onlyIdempotent

Generate a validated global ABAP class that calls the SAP Generative AI Hub via the ABAP AI SDK, with correct ISLM API shapes instead of guessed class names.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prefixNoCustomer namespace prefix for both scenarioName and className.Z
classNameNoGenerated global class name, e.g. "ZCL_AI_TRAVEL_SUMMARY". Defaults to "<prefix>CL_AI_<INTERACTION>" when omitted; must start with the chosen prefix.
functionsNoTool/function definitions for interaction "function-calling"; ignored for every other interaction. A single illustrative demo function is generated when this is left empty.
interactionYesWhich SAP AI SDK interaction shape to generate: "string", "messages", "prompt-template", "function-calling", "structured-output", "streaming", or "orchestration" — see the tool description for what each one calls.
scenarioNameYesISLM intelligent-scenario name the generated class calls via CREATE_INSTANCE( ), e.g. "ZDEMO_AI_SCENARIO". Must start with the chosen prefix; the scenario itself must already exist, be published, deployed and activated in the target system (see setupSteps) — this tool never creates it.
withUnitTestNoAlso generate a FOR TESTING skeleton class reusing the injectable seam with cl_abap_testdouble; the skeleton asserts a TODO fail( ) until you replace it with real given/when/then logic.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesThe generated class file, plus a testclasses file when withUnitTest is true.
nextStepsYesWhat to fill in or verify next, specific to the chosen interaction.
scopeNoteYesExactly what this tool does and does not do — no LLM calls, no scenario creation, no deployment, no network access.
validatedYesTop-level echo of the file-level label: syntax-checked against bundled stubs only, not SAP's real API surface.
setupStepsYesThe manual AI Core / ISLM configuration this code depends on at runtime (extended service plan, SAP_COM_0A69, INTS/INTM, F4469/F4470 deploy+activate) — this tool performs none of it.
constraintsYesDocumented limits: temperature range, per-instance parameter persistence, catchable error codes via IF_AIC_API_ERROR, ABAP Cross Trace debugging, and — for interaction "orchestration" only — the three completion-API features it does not yet support.
validationIssuesYesabaplint findings on the generated sources — empty on a clean round-trip.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that round-tripping through abaplint only proves the ABAP parses and not exact API-surface fidelity, that the constructor seam enables cl_abap_testdouble, and that manual ISLM/cockpit steps are returned in setupSteps because the tool has no SAP system, credentials, or network. No contradiction with readOnlyHint/idempotentHint/openWorldHint.

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?

The single dense paragraph front-loads the core action and the SDK disambiguation before the seven-shape enumeration. It is long, but nearly every clause carries substantive, non-redundant information; the length is the main cost against a 5.

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 generator with an output schema, the description covers scope, safety boundary, validation method, testing seam, and manual prerequisites, leaving nothing an agent needs in order to call it correctly unstated.

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 real meaning for the interaction enum by explaining what each of the seven shapes actually calls (EXECUTE_FOR_STRING, the tool-call DO-loop, IF_AIC_ADT_COMPLETION_API, etc.) and notes that 'functions' is ignored for other interactions.

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: 'Generate one validated global ABAP class that calls the SAP Generative AI Hub through the ABAP AI SDK ... ISLM.' It explicitly disambiguates from a third-party SDK with a similar name and clearly differentiates from sibling scaffolders like scaffold_rap_bo and scaffold_abap_unit.

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?

Gives explicit when-to-use ('adding a Generative-AI-Hub call to ABAP Cloud code ... instead of guessing') and when-not (no LLM call, no deploy/activate, no comm-arrangement or INTS/INTM creation). It does not route to a sibling alternative, so it stops just short of a full 5.

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