abap-config-mcp

Move Transport Objects or Task

transport_move

Move object entries or reassign a whole task between transport requests and tasks, with a dry run by default that previews SAP's test move, cross-request usage and release order before committing.

Instructions

Move object entries from one transport request/task to another, or reassign a whole task to another request — with the checks a careful Basis colleague makes first. DRY RUN by default: shows the plan, runs SAP's own test move (TR_MOVE_OBJECTS test mode), and reports what the moved objects use and are used by on other open requests, with the release order that follows. commit: true moves and verifies in E071.

objects given → those entries move ("R3TR CLAS ZCL_X", "CLAS ZCL_X", "ZCL_X", "ZCL_FOO*"); an object's parts (methods, sections, includes, function modules) move with it unless includeParts: false. no objects, from = a task → the whole task moves to the target request (TR_REASSIGN_TASK).

Stops before SAP is called when a request is released, the kinds differ (Workbench/Customizing), or the clients differ; warns when the target goes to another system or an object would be split.

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": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "transport_move"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Target request (or a task in it)
`from`	Yes	Source request or task
`commit`	No	Actually move (default false = dry run with SAP's test move)
`objects`	No	Entries to move: "R3TR CLAS ZCL_X", "CLAS ZCL_X", "ZCL_X" or a wildcard "ZCL_FOO*". Omit with a task as from to move the whole task.
`autoDeploy`	No	Deploy/update the in-system engine if needed (default true)
`connectionId`	No	SAP system connection ID
`includeParts`	No	Move an object's parts with it (default true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.16.0Nov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations, which only say it is not read-only, not idempotent, and touches an open world. The description discloses that it defaults to a dry run using SAP's own TR_MOVE_OBJECTS test mode, what the plan reports (usage by/on other open requests plus release order), that commit verifies in E071, and the exact preconditions that abort before SAP is called (released request, Workbench vs Customizing mismatch, client mismatch) plus warnings for cross-system targets and object splitting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well organized: the dry-run default and commit toggle are front-loaded, then an indented two-line branch table for the object-vs-task cases, then the abort/warn conditions. Every line carries operational information and nothing is repeated verbatim from the schema.

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 mutating transport tool with no output schema, the description covers the mode selection, the dry-run/commit contract, the failure preconditions, and the content of the report an agent gets back (usage links and release order). An agent has enough to call it safely without trial and error.

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 already 100%, so the baseline is 3, but the description adds real semantics: the accepted object string forms and wildcard, that omitting objects with a task as 'from' moves the whole task, that includeParts: false suppresses moving an object's parts, and that commit triggers the verified real move. Much of this mirrors the schema text, which keeps it from a 5.

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 and resource ('Move object entries from one transport request/task to another, or reassign a whole task'), and immediately distinguishes the two operating modes. Against siblings like manage_transport_requests, an agent can tell this is the cross-request object mover 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 Guidelines4/5

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

Gives explicit routing rules: with 'objects' those entries move; with no objects and from = a task the whole task is reassigned via TR_REASSIGN_TASK. It also states the default is a dry run and that commit: true performs the real move, which tells the agent when each mode applies. It stops short of naming sibling tools to use for other transport operations, so it is clear context rather than a full alternatives map.

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

Deploy Server