abap-config-mcp

Create ABAP Object

create_abap_object

Create ABAP development objects—programs, classes, function groups, includes, tables—in a target package, and reuse or create the required transport request.

Instructions

Create a new ABAP development object (program, class, function group, include, table, etc.) in a package. A local package ($TMP) needs no transport. Creating a function group include (FUGR/I) also adds its INCLUDE line to the group's main program — do not add it again. Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "objectType": "<objectType>",
      "name": "<name>",
      "description": "<description>",
      "packageName": "<packageName>"
    },
    "name": "create_abap_object"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Object name (e.g. Z_MY_PROGRAM)
`workItem`	No	Name of the piece of work (e.g. HPM, a ticket). Keeps using the same transport for it across calls and sessions until you pass another.
`transport`	No	Workbench request to record into. Checked before use; becomes the transport for this piece of work.
`objectType`	Yes	ABAP object type. Full typeId (PROG/P, CLAS/OC, FUGR/F, TABL/DT, DTEL/DE, DOMA/DO, INTF/OI) or the bare prefix (PROG, CLAS, FUGR, TABL, DTEL, DOMA, INTF, …) — the bare form is normalised to the full typeId.
`parentPath`	No	Parent ADT URL — defaults to /sap/bc/adt/packages/<packageName>
`description`	Yes	Object short description
`packageName`	Yes	Target package (e.g. ZDEV_PKG)
`connectionId`	No	SAP system connection ID
`createTransport`	No	Create a NEW Workbench request (only when you mean it; existing requests are preferred).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.16.0Nov 12, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true — they reveal nothing about side effects or transport semantics. The description adds the important hidden behavior: creating a FUGR/I include mutates the group's main program, and it lays out a full transport-resolution precedence (passed transport → existing object lock → createTransport:true → workItem/session reuse → single open request → list for choice → offer creation). That is genuine value beyond the structured fields.

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 correctly: purpose first, then the include/transport caveats. However, the closing transport sentence is a single chain of semicolon-separated clauses that is harder to parse than the rest of the text and could be a short precedence list. Overall dense and largely waste-free.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no output schema, the description covers purpose, side effects, and transport resolution well. Gaps remain: it never says what a successful call returns (no output schema to fall back on), and it omits that the created object typically still needs activation via abap_activate before use — relevant context given the sibling set.

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

Parameters3/5

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

Schema description coverage is 100%, so per-parameter meaning (objectType normalisation, parentPath defaulting to the package URL, workItem persistence) is already documented in the schema and the description largely restates it. Its added value is compositional — it explains how transport, workItem, and createTransport interact as a precedence chain rather than as isolated params — but that is a modest increment over an already-complete schema, landing at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Create a new ABAP development object') and enumerates the supported object families (program, class, function group, include, table), plus scoping to a package. It stops short of distinguishing itself from near neighbours like create_test_include or create_package, so it reads as clear-but-undifferentiated rather than a sibling-routing 5.

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 real context: a $TMP local package needs no transport, and for FUGR/I the INCLUDE line is added automatically so the caller must not add it again — an explicit do-not-do instruction. What's missing is routing guidance for the crowded create/activate surface (e.g., when to prefer create_test_include, or that activation is a separate step via abap_activate).

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

Deploy Server