Skip to main content
Glama
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

RuntimeRunClassWithProfiling

Execute an ABAP class with profiling enabled, then poll the profiler feed for the trace ID this run produced. Deprecated; prefer the standard run tool with profile=true.

Instructions

[runtime][deprecated] Execute ABAP class with profiler enabled: schedules a trace, runs the class under it, then searches the profiler feed for the trace id this run produced (bounded by max_trace_attempts/trace_retry_delay_ms). trace_id is absent if the trace has not appeared within that bound. No run_status or trace_requests_status field is returned — the client exposes no transport status for a run. Prefer RuntimeRunClass with profile=true; this tool is kept for backward compatibility and will be removed in a future major release.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aggregateNo
sql_traceNo
amdp_traceNo
class_nameYesABAP class name to execute.
descriptionNoProfiler trace description.
all_db_eventsNo
explicit_on_offNo
with_rfc_tracingNo
all_dynpro_eventsNo
trace_lookup_urisNoAccepted for backward compatibility; no longer affects trace lookup. adt-clients 19 lists the profiler feed as one endpoint, optionally filtered by user — there is nowhere to put a URI.
max_trace_attemptsNoMax attempts to poll the profiler feed for the trace this run produced (default 5). Increase for slow systems (e.g. SAP trial cloud).
all_procedural_unitsNo
max_time_for_tracingNo
trace_retry_delay_msNoDelay in ms between profiler-feed polling attempts (default 2000).
max_size_for_trace_fileNo
all_misc_abap_statementsNo
all_system_kernel_eventsNo
all_internal_table_eventsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv16.0.0
    • changedInput schema / properties / max_trace_attempts / description
      Previous value: -"Max polling attempts to resolve traceId after execution (default 5). Increase for slow systems (e.g. SAP trial cloud)."New value: +"Max attempts to poll the profiler feed for the trace this run produced (default 5). Increase for slow systems (e.g. SAP trial cloud)."
    • changedInput schema / properties / trace_lookup_uris / description
      Previous value: -"Additional URIs to consult when resolving the trace (advanced)."New value: +"Accepted for backward compatibility; no longer affects trace lookup. adt-clients 19 lists the profiler feed as one endpoint, optionally filtered by user — there is nowhere to put a URI."
    • changedInput schema / properties / trace_retry_delay_ms / description
      Previous value: -"Delay in ms between trace polling attempts (default 2000)."New value: +"Delay in ms between profiler-feed polling attempts (default 2000)."
  2. Changed3 schema fields changedv6.7.0
    • addedInput schema / properties / max_trace_attempts
      Added value: +{
+  "description": "Max polling attempts to resolve traceId after execution (default 5). Increase for slow systems (e.g. SAP trial cloud).",
+  "type": "number"
+}
    • addedInput schema / properties / trace_lookup_uris
      Added value: +{
+  "description": "Additional URIs to consult when resolving the trace (advanced).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / trace_retry_delay_ms
      Added value: +{
+  "description": "Delay in ms between trace polling attempts (default 2000).",
+  "type": "number"
+}
  3. Added

TDQS

A4.4/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 well: it discloses the trace scheduling flow, the bounded polling via max_trace_attempts/trace_retry_delay_ms, the failure mode (trace_id absent), and explicitly states that no run_status or trace_requests_status is returned. This is unusually rich behavioral context for a deprecated tool.

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?

Front-loaded with the action, then the mechanism, then the deprecation guidance. Efficient despite the density; every sentence adds information, though the run_status/trace_requests_status sentence could be tightened.

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 complex 18-parameter tool with no output schema, the description covers the important runtime semantics and the return-value caveat (trace_id may be absent, no status fields). The main gap is the unexplained boolean trace-configuration parameters, but the core behavior is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 28% with 18 parameters, so the description should compensate but mostly does not. It references max_trace_attempts/trace_retry_delay_ms, but those already have schema descriptions, and the many undocumented boolean trace flags (aggregate, sql_trace, amdp_trace, all_db_events, etc.) get no explanation here.

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 (execute ABAP class with profiler enabled) and goes further by describing the mechanism: schedule trace, run class, poll profiler feed. It also explicitly distinguishes itself from the sibling RuntimeRunClass with profile=true.

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?

Directly names the preferred alternative (RuntimeRunClass with profile=true) and states the condition for still using this one (backward compatibility, removal in a future major release). Both when-to-use and when-not-to-use are explicit.

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