Skip to main content
Glama

SAPTransport

Destructive

Manage SAP CTS transport requests (SE09/SE10) by listing, creating, releasing, deleting, reassigning, and checking transport needs for packages and objects across SAP ABAP systems.

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=modifiable, R=released.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoTransport request ID, e.g. A4HK900123 (required for get/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.
userNoSAP user for list (default: current user; "*" means all users).
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. 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.
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)
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.
Behavior4/5

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

Annotations declare destructiveHint=true, and the description expands on this substantially: removeLockedObjects explains the HTTP 400 failure path, create explains the SE09/SE10 fallback for SAP_BASIS 7.50, and history is explicitly flagged as 'legacy name... not complete transport history'. The description discloses runtime behaviors like 'SAP validates the target — an unknown target is rejected' and 'an empty target means a LOCAL request (cannot be transported onward)'. It adds meaningful context beyond the raw annotation, though it doesn't fully spell out confirmations/prompts on destructive actions.

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?

Most parameters have tightly-scoped one-to-two-sentence descriptions with concrete examples and failure modes (e.g. 'SAP_BASIS 7.50 rejects it with "user action is not supported"'). Some entries are long but every clause carries behavioral or semantic weight. The action parameter's description is dense but necessary given 10 distinct actions. The passage is front-loaded with the action list and status/id facts before diving into parameter detail. A few descriptions (target, transportLayer) are verbose but justified by real-world failure complexity.

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 17-parameter tool with no output schema and no sibling-filtering need (this is the sole transport tool alongside generic SAP* siblings), the description covers actions exhaustively, addresses edge cases (empty target, locked objects, layer resolution fallback), documents cross-system constraints (CTC, SAP_BASIS version), and gives runtime hints (cheaper list summaries, read-only actions). Every parameter is documented with usage, defaults, and constraints. The create path alone documents four independent routing knobs (target, package, transportLayer, layers/targets discovery endpoints) with explicit ordering guidance about which to omit.

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 per the rubric baseline is 3. The description adds substantial incremental value: create's target parameter gets deep guidance on forms (system, system.client, /group/), CTC requirements, and the tm:root/newrequest endpoint limitation on SAP_BASIS 7.50. transportLayer explains when to omit it entirely, and pgmid is clarified with 'object type alone does not determine pgmid'. The action parameter's description is effectively the tool's full user manual, adding far more than the enum itself conveys.

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 opens with the specific verb 'Manage CTS transport requests (SE09/SE10)' and immediately enumerates all actions (list, get, create, release, delete, remove_object, reassign, release_recursive, check, history). It distinguishes each action clearly and the final note explains ID format and status codes. The create action insight ('Workbench (K) request — the package/target sets target & layer, not the request category') demonstrates deep tool understanding that differentiates from any possible sibling.

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?

The description provides explicit when-to-use guidance: 'summary=true for a headers-only overview... far cheaper when many transports are open', 'Use this to discover a real value instead of guessing' for layers, and distinguishes 'history (legacy name... not complete transport history)'. The action parameter gives detailed per-action usage context, including which actions don't require write scope and which require specific inputs (remove_object needs full key pgmid+type+name). Clear exclusions like 'works without SAP_ALLOW_TRANSPORT_WRITES' help route decisions.

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

Install Server

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