Skip to main content
Glama

SAPTransport

Destructive

Manage SAP CTS transport requests: list, create, release, delete, reassign, and inspect differences and object locks across requests and tasks.

Instructions

Manage CTS transport requests (SE09/SE10). Actions: list (current user, modifiable), get (tasks + objects), create (always a Workbench (K) request — the package/target sets target & layer, not the request category; optional explicit target), release, delete, remove_object (keep the request), reassign (change owner), release_recursive (tasks then parent), check (does a package need a transport — type, name, package), history (legacy name: current object lock plus assignment candidates — type, name; not complete transport history; read-only, no write scope needed). IDs look like A4HK900123. Status: D/L=modifiable, O/P=releasing, R/N=released.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoTransport request ID, e.g. A4HK900123 (required for get/diff/release/delete/reassign/release_recursive/remove_object)
nameNoObject name (for check, history, or remove_object actions)
typeNoObject type for check/history/remove_object actions (PROG, CLAS, DDLS, etc.). Not used by create, which creates a Workbench (K) request.
userNoList user (default: current SAP user; "*" means all visible owners).
limitNodiff: objects per call (default 20, max 40); page with offset.
ownerNoNew owner SAP username (required for reassign)
pgmidNoProgram ID for remove_object: "R3TR" (whole object) or "LIMU" (sub-object). Required — object type alone does not determine pgmid.
actionYeslist: show transports (defaults to current user, modifiable only). Pass summary=true for a headers-only overview that omits each transport's object lists (keeps an objectCount) — far cheaper when many transports are open. get: fetch transport details including tasks and objects. diff: what a transport CHANGED — per object, the revision written under it vs the one before, as diff hunks (get only lists names). LIMU entries roll up to their class; an open transport compares to the last released revision. Read baselineStatus first: prior-revision = solid; prior-revision-unverified = pair guessed, may be another change; no-prior-snapshot = created here; baseline-ambiguous = no baseline, so an all-additions block is NOT proof of creation; baseline-unavailable = the read FAILED, never call that unchanged. create: create a new transport request (description required). To target another system, pass target=<system | system.client | /group/> (the Transportziel / TR_TARGET, e.g. "/TRG/" or "C11"; the group and system.client forms require extended transport control to be active). Otherwise omit target and pass an optional package to let SAP infer the route (defaults to $TMP). The response reports the resolved transport target; an empty target means a LOCAL request (cannot be transported onward). release: release a single transport or task. delete: delete a transport (use recursive=true to delete tasks first; removeLockedObjects=true to strip locked objects that otherwise block deletion with "...contains locked objects"). remove_object: remove one object from a request, keeping the request — needs the full key pgmid+type+name. reassign: change transport owner (use recursive=true for tasks too). release_recursive: release all unreleased tasks first, then the transport itself. check: check create/modify transport needs for a package/object (requires type, name, package; operation defaults to create). history: inspect the current object lock and assignment candidates (legacy action name; not complete transport history; requires type, name; works without SAP_ALLOW_TRANSPORT_WRITES). layers: list the transport layers this system offers (name + description + resolved target where any) — the valid values for create's transportLayer. Use this to discover a real value instead of guessing; works without SAP_ALLOW_TRANSPORT_WRITES. targets: list the valid transport targets (Transportziel / TR_TARGET) this system offers — the valid values for create's target. Use this to discover a real target (e.g. before create with target=). Read-only. Both report unavailability at runtime on releases that lack the value-help endpoint.
offsetNodiff: first object to diff (default 0).
statusNoTransport status filter (for list). D=modifiable (default), R=released, "*"=all statuses.
targetNoExplicit transport target (Transportziel / TR_TARGET) for create — what the user means by "create a transport with target X". Forms: a system ("C11"), system.client ("C11.021"), or target group ("/TRG/"). The group and system.client forms require extended transport control (CTC) to be active. Created via the tm:root/newrequest endpoint (the only ADT path that sets the target directly) — this needs a newer ABAP Platform / S/4HANA; SAP_BASIS 7.50 rejects it with "user action is not supported" (an ADT-stack limitation, so set the target in SE09/SE10 there instead). SAP validates the target — an unknown target is rejected. Pass the exact value the user gives; do not invent one.
packageNoPackage name. For create: optional — defaults to $TMP; an explicit package influences the route/target, while the request remains Workbench type K. For check: required.
summaryNoFor list only. DEFAULT true: headers-only — drops each transport's (and task's) object lists, keeping id/description/owner/status/target + objectCount; use action="get" for one in full. Pass false for full object lists (~5x larger).
operationNoCheck mode: create (default) or modify.
recursiveNoApply recursively to child tasks (for delete/reassign). release_recursive always recurses.
maxResultsNoMaximum list rows or check/history assignment candidates (defaults: list/history 50, check 10; max 1000).
descriptionNoTransport description text (required for create)
resultFormatNorelease actions: legacy (default) or structured JSON.
timeoutSecondsNorelease timeout seconds: 1-1800; default 300.
transportLayerNoTransport layer for create (optional, advanced). Sent as the ?transportLayer= query param to override which consolidation route — and therefore which target — SAP resolves. OMIT IT by default: SAP resolves the target from the package automatically, which is correct for almost all cases. Never invent a value — if you need a specific layer, obtain it from action="layers" or from the user. Only effective when that layer has a classic STMS consolidation route; otherwise the request is local regardless.
removeLockedObjectsNoFor delete only. Strip locked objects from each task before deleting, so a request that still holds a locked object (e.g. a deleted object's lingering record → HTTP 400 "...contains locked objects") can be removed.
Install Server

TDQS

A4.6/5.0
Behavior5/5

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

The description is exceptionally transparent about behavior. It warns of destructive actions (delete, release) and details how to control them (recursive, removeLockedObjects). It discloses limitations (e.g., history is not complete, create always produces K request, SAP_BASIS 7.50 limitation for target). It also distinguishes read-only operations (layers, targets) and notes permission requirements ('no write scope needed'). This goes far beyond the annotations (readOnlyHint=false, destructiveHint=true) and even enriches them with actionable context. No contradiction with annotations.

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 description is long but well-structured: it opens with the overall purpose, then lists actions with embedded details, and includes status codes and caveats. Each sentence carries meaningful information; there is little fluff. While not as terse as the TDQS 4.3 example, it efficiently packs a large amount of necessary detail for a complex 21-parameter tool. The structure (action-by-action) aids scannability.

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?

Given the tool's complexity (21 parameters, 10+ actions, no output schema), the description is remarkably complete. It covers all actions, explains edge cases (e.g., $TMP default, extended transport control requirement, SAP_BASIS 7.50 fallback), provides return hints (e.g., 'response reports the resolved transport target'), and clarifies limitations (e.g., 'not complete transport history'). It effectively compensates for the missing output schema by describing expected results and failure modes.

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% with detailed per-parameter descriptions. The tool description adds further semantic context, such as defaults ($TMP), interplay between parameters (package influences target), and validation rules (target must be valid). For example, the 'action' parameter in the schema is already long, but the description adds practical guidance on when to use summary=true and how to interpret diff baselines. This adds value beyond the schema, justifying a score above the baseline of 3.

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?

The description clearly states the tool's purpose as managing CTS transport requests (SE09/SE10) and enumerates specific actions (list, get, create, release, etc.). It uses a specific verb+resource pattern and differentiates from sibling tools like SAPRead or SAPManage by focusing on transport lifecycle operations. The explicit action list and status code explanation provide unambiguous scope.

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?

The description gives clear context for when to use the tool and its actions, e.g., 'check: check create/modify transport needs' and 'history: ... works without SAP_ALLOW_TRANSPORT_WRITES'. It also notes read-only actions (layers, targets) and explains trade-offs (e.g., summary=true for cheaper list). However, it does not explicitly compare against sibling tools or state 'use this instead of X', so it lacks explicit exclusions or alternatives. Still, context is clear enough for a 4.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/arc-mcp/arc-1'

If you have feedback or need assistance with the MCP directory API, please join our Discord server