Skip to main content
Glama
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

RuntimeListFeeds

List SAP ADT runtime feeds and variants, or read ABAP short dumps, system messages, and Gateway errors filtered by user and time; dumps also filter by runtime error, exception, object, package.

Instructions

[runtime] List the ADT runtime feeds and their variants, or read one: ABAP short dumps, system messages or SAP Gateway errors, filtered by user and time range; dumps also by runtime error, exception, object, package and application component. Entries come newest first; each dump carries its dump_id. When more entries remain, next_to is the to that reads on; incomplete_second names a second holding more entries than SAP answers in one request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd of time range in YYYYMMDDHHMMSS format, inclusive; pass a previous next_to here to read on.
fromNoStart of time range in YYYYMMDDHHMMSS format.
userNoEntries of this SAP user (exact match).
packageNoDumps whose object package contains this text, in any case.
componentNoDumps whose application component contains this text, in any case.
exceptionNoDumps whose exception class contains this text, in any case.
feed_typeNoFeed to read. "descriptors" lists available feeds, "variants" lists feed variants, others read that specific feed. Default: descriptors.descriptors
max_resultsNoMost entries to return, up to 1000; SAP answers at most 100 per request and the pages are read in turn. An answer holds whole seconds, so it may hold a few entries fewer, or a crowded second more, than asked. Default: 50.
object_nameNoDumps whose terminated object name contains this text, in any case.
runtime_errorNoDumps whose runtime error contains this text, in any case.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv16.0.0
    • addedInput schema / properties / component
      Added value: +{
+  "description": "Dumps whose application component contains this text, in any case.",
+  "type": "string"
+}
    • addedInput schema / properties / exception
      Added value: +{
+  "description": "Dumps whose exception class contains this text, in any case.",
+  "type": "string"
+}
    • changedInput schema / properties / max_results / description
      Previous value: -"Maximum number of entries to return."New value: +"Most entries to return, up to 1000; SAP answers at most 100 per request and the pages are read in turn. An answer holds whole seconds, so it may hold a few entries fewer, or a crowded second more, than asked. Default: 50."
    • addedInput schema / properties / object_name
      Added value: +{
+  "description": "Dumps whose terminated object name contains this text, in any case.",
+  "type": "string"
+}
    • addedInput schema / properties / package
      Added value: +{
+  "description": "Dumps whose object package contains this text, in any case.",
+  "type": "string"
+}
    • addedInput schema / properties / runtime_error
      Added value: +{
+  "description": "Dumps whose runtime error contains this text, in any case.",
+  "type": "string"
+}
    • changedInput schema / properties / to / description
      Previous value: -"End of time range in YYYYMMDDHHMMSS format."New value: +"End of time range in YYYYMMDDHHMMSS format, inclusive; pass a previous next_to here to read on."
    • changedInput schema / properties / user / description
      Previous value: -"Filter feed entries by SAP username."New value: +"Entries of this SAP user (exact match)."
  2. Addedv6.5.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full behavioral burden and delivers real value: entries come newest first, each dump carries its dump_id, next_to is the 'to' value to continue reading, and incomplete_second signals a second holding more entries than SAP returns in one request. It stops short of stating permissions, error behavior, or the shape of the descriptors/variants output, but the pagination semantics are unusually well disclosed.

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?

Purpose and defect categories are front-loaded before the filter and pagination details, and no sentence is pure filler. The final sentence on incomplete_second is dense and jargon-heavy, slightly taxing on first read, but it conveys a genuinely needed pagination caveat.

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 10-parameter, no-required-argument tool with no output schema, the description covers ordering, the dump_id key, pagination continuation, and per-feed filter applicability, which is most of what an agent needs. It does not describe the descriptors/variants output structure or how large a variant list can be, leaving a small gap.

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 schema already documents all ten parameters and a baseline of 3 applies. The description adds genuine meaning beyond the schema by scoping which filters apply to which feed (dumps additionally filterable by runtime error, exception, object, package, application component) and by explaining the next_to-to-`to` continuation pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource (list ADT runtime feeds and variants, or read one) and enumerates the concrete feeds covered: ABAP short dumps, system messages, SAP Gateway errors. That is far more specific than the name alone, but it does not differentiate from the nearby RuntimeListSystemMessages sibling, which overlaps with the system_messages feed.

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 implies usage through the feed_type default ('descriptors' lists available feeds) and notes which filters apply to which feed, so an agent can infer how to start. However, there is no explicit when-to-use/when-not or routing statement pointing at alternatives such as RuntimeGetDumpById or RuntimeListSystemMessages.

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