Skip to main content
Glama

Drive an interactive ABAP debug session

abap_debug_session

Controls an interactive ABAP debugging session to step through code, continue to breakpoints, inspect variables and call stacks, set watchpoints, and end or terminate execution.

Instructions

One move of the program an interactive capture holds (abap_debug with interactive: true), then where it stands — its position, the code around it, the watched variables — so you decide the next move from what you see. step: statement by statement — stepMode over (default), into a call, out to the caller; count steps at once (past 20 they come back as a compact trace), until a line or until a variable changed. continue: run to the next breakpoint or watchpoint (each stop as in abap_debug), or to toLine. inspect: read any variables where it stands (or the whole frame), and the call stack. watch: set a watchpoint on a variable visible here — continue then also stops where it changes (optionally where a condition holds). end: let the program run to its end — or terminate: true to abort it, e.g. before it commits. wait: a move (or a capture) that outlasts its call — ABAP_DEBUGGER_CALL_SECONDS, default 50 s — answers running: true and goes on in the background; wait returns its answer once it is done. The program waits in a work process between calls, so end the session when you are done; it is also released after a while without a call (ABAP_DEBUGGER_IDLE_SECONDS, default 120 s) and after ABAP_DEBUGGER_SESSION_SECONDS (default 15 min). Every answer says how long it has left. Apart from terminate, it never changes variables or the program's flow.

Input Schema

NameRequiredDescriptionDefault
hitsNowatch: how many of its changes stop the run (1-50, default 1).
countNostep: how many steps (default 1; with until and no count: until it holds). More than 20 come back as a compact trace; maxSeconds and maxResultKB bound the run.
stackNoinspect: include the call stack.
untilNostep: end the steps early, once the program stands on a line of the source they started in, and/or once a variable changed.
actionYesstep: run statement by statement (stepMode, count, until). continue: run on to the next breakpoint or watchpoint, or to toLine. inspect: read variables or the call stack where the program stands. watch: set a watchpoint — continue then also stops where the variable changes. wait: the answer of a capture or move that outlasted its call (it said running: true). end: let the program run to its end (or terminate it) and close the session; on a capture still running, stop it.
toLineNocontinue: run to this line of the source the program stands in instead of the next breakpoint (it still stops at a breakpoint on the way).
sessionNoThe session id abap_debug returned (default: your current capture or session).
stepModeNostep: over (default) stays in the method; into follows a call; out returns to the caller.
variableNowatch: the variable whose change stops the run (visible where the program stands), e.g. LV_STATUS.
conditionNowatch: stop only where this ABAP condition holds once it changed, e.g. lv_status = 'E'.
terminateNoend: abort the program where it stands instead of letting it run to its end — e.g. so that it does not commit. Its open database changes are rolled back.
variablesNostep / continue: the variables to watch from now on, read after every step and at every stop (replacing the ones named before). inspect: read these now, structures expanded and tables' first rows (default: every variable of the frame).
maxSecondsNostep: time budget of this call (default 120); the server's ceiling applies.
maxResultKBNoSize budget of this answer in KB (default 40); the server's ceiling applies.
timeoutSecondsNocontinue: how long to wait for the next stop (1-900, default 60).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the critical runtime traits: the program waits in a work process between calls, calls exceeding ABAP_DEBUGGER_CALL_SECONDS return running: true and continue in the background, sessions are released after ABAP_DEBUGGER_IDLE_SECONDS (120 s) and ABAP_DEBUGGER_SESSION_SECONDS (15 min), and every answer reports remaining time. It also scopes side effects precisely — 'Apart from terminate, it never changes variables or the program's flow' — and notes that terminate aborts before commit and rolls back open database changes, which is consistent with readOnlyHint=false / destructiveHint=false.

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 purpose and the action menu are front-loaded and each action line earns its place for a six-action, fifteen-parameter tool. It is dense and uses line-broken em-dash fragments that make the first sentence harder to parse than necessary, but there is little filler.

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?

With no output schema, the description carries the burden well: it explains what each answer contains (position, surrounding code, watched variables, remaining session time, running: true for backgrounded calls) and covers the full session lifecycle including expiry and termination consequences. Nothing an agent needs to drive the session correctly appears to be missing.

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 already 100%, so the baseline is 3, but the description adds genuine cross-parameter meaning: count above 20 returns a compact trace, until ends stepping early on a line or a variable change, variables 'replacing the ones named before' across step/continue, and terminate causing rollback. It does not restate the numeric defaults for every bound (maxSeconds, maxResultKB, timeoutSeconds), leaving those entirely to the schema.

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 states a specific verb and resource — advancing an interactive ABAP debug session one move and returning position, surrounding code and watched variables — and explicitly ties it to the sibling that creates the capture ('abap_debug with interactive: true'), so an agent can tell the two apart. The opening sentence is convoluted ('One move of the program an interactive capture holds'), which slightly obscures the purpose until the per-action list clarifies it.

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?

Every action is given an explicit when-to-use: step for statement-by-statement (with stepMode/count/until), continue for running to the next breakpoint/watchpoint or toLine, inspect for reading variables and the call stack, watch for setting a watchpoint, wait for retrieving an answer that returned running: true, end for closing the session. It also states the operational rule 'end the session when you are done', naming the alternative (idle/session expiry) if you don't.

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