Skip to main content
Glama
Sign In
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

GetATCFindings

Reads ATC run findings by worklist ID, returning each finding’s object, source position, priority, check, and message, plus covered object and per-priority counts.

Instructions

[read-only] Reads the findings of the ATC run whose worklist is named by worklist_id, for a run started with wait=true or wait=false. Answers each finding with the object, the source position, the priority, which check ran and what it said, plus how many objects were covered and the counts per priority. 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. Recordable: in batch mode a call is recorded under the next number and answers with empty content; its answer is read by number after the batch ends.

Input Schema

NameRequiredDescriptionDefault
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.
worklist_idYesWorklist identifier an ATC run answered.

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 / worklist_id / description
      Previous value: -"Worklist identifier answered by RunATC."New value: +"Worklist identifier an ATC run answered."
  2. Addedv16.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Without annotations the description carries the full burden and does so well: it discloses read-only semantics, that it runs on its own ABAP session, exactly what happens when timeout fires (read cancelled, session logged off, system unchanged), that a client-side cancel only ends the client's wait while SAP continues, and how batch recording returns empty content that must be read by number.

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 core purpose is front-loaded in the first clause and the return contents follow, but the timeout explanation is long and largely duplicates the schema text. Dense punctuation makes it heavier than needed for a three-parameter tool, though no sentence is truly dead weight.

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?

There is no output schema, and the description compensates by enumerating what each finding answers with (object, source position, priority, check, message) plus coverage and per-priority counts. For a read-only tool it leaves nothing an agent needs to call it correctly.

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 coverage is 100%, so the schema already documents detail, timeout and worklist_id fully. The description restates the timeout semantics and client-limit guidance almost verbatim rather than adding new meaning, though it does contribute the prerequisite that worklist_id comes from a wait=true/false run.

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: reads the findings of an ATC run identified by worklist_id, and specifies the run must have been started with wait=true or wait=false. An agent can distinguish this from RunATC (starts a run) and GetATCRunStatus (checks status) 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 clear context: use after an ATC run has produced a worklist, and explains the practical trigger for setting timeout and the effect of batch mode. It never explicitly names GetATCRunStatus as the alternative or states when not to use this tool, which keeps it short of a 5.

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