Skip to main content
Glama

DebugStartListener

Arms ABAP breakpoints, starts listening, and attaches to the first matching debuggee, enabling user-mode or terminal-mode debugging of SAP requests.

Instructions

[read-only] [debug] Opens a debug session: arms breakpoints, listens for a debuggee and attaches the first one caught; refused before anything is placed while another debugger listens for that user. Needs at least one breakpoint. Takes whose requests are caught, the debugging mode and the debugger settings. In user mode it catches every request of the request user (the connected SAP user, or the one named), from this server and from anywhere else. Its breakpoints are one set, shared by every IDE of the same SAP user (in user mode, debugging the same request user; in terminal mode, whatever its ids), and each change rewrites that set as a whole. Runs outside batch mode.

Input Schema

NameRequiredDescriptionDefault
runNoA class (as a console application) or a report started in the background once listening; its outcome is reported as the end of the session.
detailNoHow much of the answer to return: "terse" (default, the fields you need to act), "full" (the whole parse), "raw" (the document as ADT sent it).terse
settingsNoDebugger settings, applied after each attach; a field left out keeps its value.
breakpointsYesBreakpoints, at least one: a line, an exception class, an ABAP statement or a message; a line breakpoint may carry a condition.
request_userNoUser mode: the SAP user whose requests are caught; the connected user when omitted. Debugging another user's requests needs the debug authorization for that user. Not taken in terminal mode.
debugging_modeNouser (when omitted) catches the requests of the request user; terminal catches the requests that carry this debug session's ids and needs no configuration: the run it starts carries them, so without run it catches only requests carrying the same ids.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv20.1.0

TDQS

A4.9/5.0
Behavior5/5

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

It provides rich behavioral context beyond the schema, detailing that breakpoints are 'one set, shared by every IDE of the same SAP user,' that changes 'rewrites that set as a whole,' and specifies the constraint of running 'outside batch mode.'

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 description is very dense, serving as a comprehensive block of text rather than short, punchy bullet points. However, every sentence contributes unique, necessary context to the complex function.

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?

Given the high parameter count, multiple modes, and shared-state semantics of the tool, this description captures virtually all the necessary operational and logical constraints an AI agent would need for accurate execution.

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

Parameters5/5

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

While schema coverage is 100%, the description adds critical semantic meaning, explaining the difference between 'user mode' (catching every request of the request user) and 'terminal mode' (catching requests with specific IDs), which is not obvious from the enum definitions alone.

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?

The tool's purpose is explicitly defined: it 'Opens a debug session: arms breakpoints, listens for a debuggee and attaches the first one caught.' This provides a precise function and outcome.

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?

The description provides clear usage constraints and when the tool will fail, stating it 'Needs at least one breakpoint' and is 'refused before anything is placed while another debugger listens for that user.'

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