Skip to main content
Glama

RuntimeRunProgram

Runs an ABAP program or report by name and returns its output; optionally starts a profiler trace for later retrieval and supports background execution.

Instructions

[read-only] [runtime] Runs the ABAP program (report) named by program_name and returns its output. Set profile=true to also start a profiler trace; the trace is then found in the list of profiler trace files (program execution is fire-and-forget, so the traceId arrives later, through that list). When profile is any value but true, 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
profileNoWhen true, run with the profiler. Default false. Trace must be located afterwards via RuntimeListProfilerTraceFiles — program execution does not return traceId synchronously.
aggregateNo
sql_traceNo
amdp_traceNo
backgroundNoWhen true, the run goes on in the background on an ABAP session of its own and the call answers at once with a run_handle; read its answer later with GetBackgroundRun, and remove it with DiscardBackgroundRun. A started run cannot be stopped. No default: without it the call waits for the run to end.
descriptionNoProfiler trace description (only used when profile=true).
program_nameYesABAP program name to execute.
all_db_eventsNo
explicit_on_offNo
with_rfc_tracingNo
all_dynpro_eventsNo
all_procedural_unitsNo
max_time_for_tracingNo
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. Addedv20.1.0

TDQS

B3.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden and does well: it discloses fire-and-forget execution, that the traceId arrives asynchronously via the trace file list, and batch-mode recording behavior. It omits permissions, failure modes, and what the returned output looks like, but the async/side-effect profile is clearly surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Leads with the core action, which is good, but the batch-mode sentence ('When profile is any value but true, recordable: in batch mode a call is recorded under the next number...') is convoluted and hard to parse. It is dense and not cleanly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 annotations, the description leaves most tracing parameters unexplained and does not describe the returned output format. It adequately covers the common path but is incomplete given the tool's complexity.

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 24% and there are 17 parameters. The description explains program_name indirectly and profile=true, but the 12 tracing/aggregation flags (aggregate, sql_trace, amdp_trace, all_db_events, max_time_for_tracing, etc.) are undocumented in both schema and prose, leaving most parameters opaque.

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?

States a specific verb and resource: 'Runs the ABAP program (report) named by program_name and returns its output.' This clearly distinguishes it from RuntimeRunClass, though it does not name that sibling explicitly. The added note about firewall-like behaviors (fire-and-forget) is extra.

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 concrete when-to-do-what guidance: set profile=true to start a trace located via the profiler trace file list, and use background/GetBackgroundRun/DiscardBackgroundRun for async execution. It does not say when to prefer this over RuntimeRunClass or RunProgramUnitTest, keeping 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