Skip to main content
Glama
Sign In
mcp-abap-adt

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ListTransports

Lists transport requests for the current or a specified SAP user, returning modifiable and released workbench and customizing requests.

Instructions

[read-only] List transport requests for the current or specified user. Returns modifiable and/or released workbench and customizing requests. user and modifiable-only are both applied client-side, over every request the server's default search configuration answers; ADT receives the default search alone. Runs on an ABAP session of its own. Optional timeout (seconds): when it passes, the read is cancelled, its ABAP session logged off, and the system stays as it was. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a client's cancel ends only the client's wait, and SAP runs the read on. Runs outside batch mode.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ListTransports"
  }
}

Input Schema

NameRequiredDescriptionDefault
userNoThe user to filter to: an SAP user id (matched in upper case); applied client-side. If not provided, defaults to the current session user, so an unfiltered call already answers only that user's transports.
detailNoHow much of the answer to return: "terse" (default, the fields you need to act), "full" (the whole parse), "raw" (the document as ADT sent it).terse
timeoutNoSeconds to wait for the answer: a whole number, at least 1, no default — without it the call waits until SAP answers. When it passes, the read is cancelled (its ABAP session is logged off) and the call answers that nothing was changed. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a cancel does nothing to SAP.
modifiable_onlyNoOnly return modifiable (not yet released) transports; applied client-side. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv20.1.0
    • addedInput schema / properties / timeout
      Added value: +{
+  "description": "Seconds to wait for the answer: a whole number, at least 1, no default — without it the call waits until SAP answers. When it passes, the read is cancelled (its ABAP session is logged off) and the call answers that nothing was changed. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a cancel does nothing to SAP.",
+  "maximum": 2147483,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / user / description
      Previous value: -"SAP user name to filter to; applied client-side. If not provided, defaults to the current session user, so an unfiltered call already answers only that user's transports."New value: +"The user to filter to: an SAP user id (matched in upper case); applied client-side. If not provided, defaults to the current session user, so an unfiltered call already answers only that user's transports."
  2. Changed3 schema fields changedv16.0.0
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "terse",
+  "description": "How much of the answer to return: \"terse\" (default, the fields you need to act), \"full\" (the whole parse), \"raw\" (the document as ADT sent it).",
+  "enum": [
+    "terse",
+    "full",
+    "raw"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / modifiable_only / description
      Previous value: -"Only return modifiable (not yet released) transports. Default: true."New value: +"Only return modifiable (not yet released) transports; applied client-side. Default: true."
    • changedInput schema / properties / user / description
      Previous value: -"SAP user name. If not provided, returns transports for the current user."New value: +"SAP user name to filter to; applied client-side. If not provided, defaults to the current session user, so an unfiltered call already answers only that user's transports."
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it declares '[read-only]', states it runs on its own ABAP session outside batch mode, and precisely defines timeout/cancel semantics (the read is cancelled, its ABAP session logged off, the system stays as it was; a client-side cancel only ends the client's wait while SAP keeps running).

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 purpose is front-loaded and the sentence order moves from what it returns to how it runs. It is dense and slightly repetitive — the timeout/cancel explanation largely duplicates the `timeout` schema description — but every sentence adds signal, so waste is minimal.

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 filtered-list tool with no output schema, the description covers return content, the `detail` verbosity levels, client-side filtering scope, session isolation, and timeout behavior well enough to call it correctly. Minor shortfall is the lack of explicit alternative-tool routing, which matters in a catalog full of transport siblings.

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 the baseline is 3, but the description adds a genuinely useful nuance absent from the schema: `user` and modifiable-only are applied client-side over the server's default search, while ADT receives only the default search. That meaningfully changes how an agent should interpret results and choose parameters.

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 a specific verb and resource ('List transport requests') and then narrows scope: 'for the current or specified user', returning 'modifiable and/or released workbench and customizing requests'. An agent can tell it apart from single-object siblings like GetTransport or mutation siblings like CreateTransport without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It surfaces defaults clearly ('user defaults to the current session user', 'modifiable_only default true'), which is useful context for choosing whether to call unfiltered. But it never states when to use this over alternatives such as GetTransport (single request) or ReadTransportObjects, leaving the routing decision implied.

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

Deploy Server

Other Tools