abap-config-mcp

Create Package

create_package

Create a new ABAP package (DEVC) under an existing parent package and return its settings, recording it on a Workbench request or local $TMP as needed.

Instructions

Create a new ABAP package (DEVC) under an existing parent package and return its settings. Writes to the repository and is recorded on a Workbench request; the transport is chosen as described for write_abap_object_source, and a local package ($TMP) needs none. Add objects afterwards with create_abap_object. Needs development authorization (S_DEVELOP) and a software component and transport layer that exist in the system.

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": {
      "name": "<name>",
      "description": "<description>",
      "parentPackage": "<parentPackage>"
    },
    "name": "create_package"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	New package name, in the customer namespace (e.g. ZORDER_API_TESTS)
`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.
`description`	Yes	Short description of the package
`packageType`	No	Package type: development (default, contains objects), structure (grouping only), main (top-level)
`swComponent`	No	Software component (e.g. HOME, LOCAL, or a custom component). Leave empty for local packages.
`connectionId`	No	SAP system connection ID
`parentPackage`	Yes	Existing package to create it under (e.g. ZORDER_API)
`transportLayer`	No	Transport layer (e.g. Z, SAP). Controls which transport route is used.
`createTransport`	No	Create a NEW Workbench request (only when you mean it; existing requests are preferred).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.16.2Nov 12, 2026

changedInput schema / properties / name / description

Previous value: -"Package name (e.g. ZCAR_MM_REPORTS)"New value: +"New package name, in the customer namespace (e.g. ZORDER_API_TESTS)"

changedInput schema / properties / parentPackage / description

Previous value: -"Parent package this package lives under (e.g. ZCAR_MM)"New value: +"Existing package to create it under (e.g. ZORDER_API)"

First observedv1.16.0Nov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only flag it as a non-read-only, non-idempotent, open-world write. The description adds substantive behavior beyond that: it writes to the repository, gets recorded on a Workbench request, and defers transport selection to the write_abap_object_source convention unless the package is local ($TMP). It also discloses the required authorization object and system-level preconditions.

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?

Three sentences, front-loaded with what is created and where, then the write/transport implications, then prerequisites. Mildly dense in places—the transport rule is delegated to another tool's description rather than restated—but nothing is wasted.

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 10-parameter, non-idempotent write tool with no output schema, the definition covers purpose, side effects, transport behavior, and authorization adequately, and notes that settings are returned. Minor residual gaps are around failure/retry semantics and the exact returned settings, which the idempotentHint=false annotation partly signals.

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 all ten parameters are already documented, including the transport/workItem pairing and the packageType enum. The description only adds indirect semantics (parent package must exist, swComponent irrelevant for local packages), so the baseline 3 applies.

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 and resource ("Create a new ABAP package (DEVC) under an existing parent package") plus the return expectation ("return its settings"). It also distinguishes its role from the sibling create_abap_object, which is for objects placed inside the package afterward.

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?

Explicitly routes the agent: use this first, then "Add objects afterwards with create_abap_object." It also gives the exception condition that a local package ($TMP) needs no transport, and states the preconditions (existing software component and transport layer, S_DEVELOP authorization) that decide whether the call can succeed.

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

Deploy Server