Skip to main content
Glama

Run ABAP Report

sap_run_report
Destructive

Run an ABAP report on the SAP system and retrieve its list output as text. Confirm standard or namespaced programs to execute them with real side effects.

Instructions

EXECUTES an ABAP report (program) on the SAP system and returns its list output as text. This runs real code with real side effects — the report may post documents, change configuration, lock objects or run for minutes. It is not a preview and there is no dry run.

The report runs synchronously (SUBMIT ... EXPORTING LIST TO MEMORY AND RETURN) inside the HTTP work process, so the output comes back in the same call, typically in under a second for a small report.

Args:

  • program_name (string): the report to run.

  • confirm_non_custom (boolean): must be true for any program not starting with Z or Y. Namespaced programs (/ABC/...) count as non-custom and need it too.

  • strip_list_header (boolean, default true): remove the ABAP list header lines.

  • max_chars (number): cap on returned characters (default 20000, max 60000).

  • response_format.

Returns (json): { programName, exists, authorized, ok, output, rawOutput, lineCount, bytes, durationMs, truncated, message }. ok=false means the run did not happen or produced no usable result — ALWAYS read ok, never assume success.

Examples:

  • "Run my report ZFI_CHECK and show the output" -> program_name='ZFI_CHECK'.

  • "Run the standard report RSUSR002" -> program_name='RSUSR002', confirm_non_custom=true (and be sure that is wanted). SELECTION-SCREEN PARAMETERS CANNOT BE PASSED:

  • The SAP endpoint's SUBMIT has no WITH clause, so a report with a selection screen runs on its DEFAULT values, silently. No client can work around this. If a report needs input, give its parameters DEFAULT values, generate a variant-free wrapper report, or use sap_job_schedule. Clean output via RESULT_TEXT (the reason to prefer this over scraping a list):

  • The handler ends with IMPORT result_text FROM MEMORY ID 'RESULT_TEXT'. A report that does EXPORT result_text = lv_string TO MEMORY ID 'RESULT_TEXT'. gets that exact string back — no list header, no 255-byte padding, no CRLF records. For a report you generate, emit JSON that way and read it back verbatim.

  • Use one channel or the other. A report that both WRITEs and exports gets the result string appended after the list, and the handler never clears RESULT_TEXT — a value left by an earlier run can reappear, so do not treat its presence as proof this run produced it. Notes:

  • HTTP 200 does not mean success: SAP answers "program does not exist" and authorization refusals with 200 and a plain sentence. This tool classifies the body and reports exists/authorized/ok accordingly, keeping the untouched body in rawOutput.

  • Empty output is a legitimate result for a report that WRITEs nothing, and is also what a report that terminates early looks like — the endpoint cannot tell them apart.

  • Only classic list output (WRITE) is captured. ALV grids and screens have no GUI to render into and are not tested on this system.

  • The only server-side gate is S_DEVELOP (OBJTYPE=PROG, ACTVT=16), which a developer passes for EVERY program including SAP standard. The Z/Y namespace rule enforced here is the real safety boundary.

  • A timeout does not cancel the report — it keeps running server-side. For long-running work use sap_job_schedule, which runs in the background and returns a job id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_charsNoCap on returned output characters (default 20000).
program_nameYesReport/program name (e.g. 'ZFI_FSV_RECREATE'). Case-insensitive.
response_formatNoOutput format: 'markdown' (human-readable, default) or 'json' (structured).markdown
strip_list_headerNoDrop the standard ABAP list header (date / title / page number and the dashed rule) from the output.
confirm_non_customNoRequired true to run a program outside the Z*/Y* namespace (SAP standard reports and namespaced /ABC/ programs). Running standard reports can post documents, change configuration or run for a long time; the server refuses without this flag.
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true, but the description goes far beyond that: real side effects, no dry run, HTTP 200 not implying success, timeout not cancelling the report, RESULT_TEXT not being cleared, and only classic list output being captured. This fully discloses the behavioral risks and edge cases.

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

Conciseness5/5

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

The description is long but dense, organized into labeled sections with no filler. Every paragraph addresses a distinct concern: core behavior, arguments, return shape, examples, selection-screen limitation, RESULT_TEXT usage, and operational caveats. For a high-risk tool with this much behavioral nuance, the length is appropriate.

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, but the description fully documents the JSON return fields and stresses that ok=false must always be checked. It also covers auth, empty-output ambiguity, server-side execution after timeout, and the correct alternative for background execution. Nothing critical is missing for an agent to call this safely.

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. The description adds meaningful nuance beyond the schema, especially that namespaced programs like /ABC/ count as non-custom and require confirm_non_custom, and it clarifies max_chars defaults and caps. Some parameter explanation duplicates the schema, but the edge-case clarity justifies a 4.

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 ('EXECUTES an ABAP report'), the resource, and the return value ('list output as text'). It clearly distinguishes this from siblings like sap_syntax_check or sap_run_unit_tests by focusing on executing a report program, and explicitly notes it is not a preview.

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?

Provides explicit when-to-use guidance and names the alternative: use sap_job_schedule for reports needing selection parameters or long-running work. It also tells the agent when confirm_non_custom is required and warns that standard reports may have side effects, so the agent can decide before calling.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/appmaster3000/sap-abap-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server