Skip to main content
Glama
Freight-Art

abapsmith

by Freight-Art
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

abap_trace

Destructive

Trace ABAP runtime executions to measure call times and database accesses, then read, list, or delete the recorded runs.

Instructions

ABAP runtime tracing (SAT): records everything a traced request's dispatch touches — time per call and every database access. op="run" (default) traces one execution of a class/report and reads the result back; op="start" arms a request to trace a later run yourself; op="list" shows existing runs/requests; op="read" reads a run's hit list, DB accesses, or call tree; op="delete" removes a run or request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoA trace run id (op=read) or run/request id (op=delete); bare id or the full path a previous list/create answered with.
opNoOperation. Default "run". One of: start, run, list, read, delete.
topNoCap on rows shown. Default 20, max 100. op=read (hitlist/tree) and op=run only.
kindNoWhat to list. Default "runs". One of: runs, requests. op=list only.
rootNoAnchor the tree view at the first call-tree node matching this text (case-insensitive substring on description or calling-program name), overriding the automatic entry-node anchor. op=read view=tree only.
typeNoADT type, e.g. CLAS/OC, when ambiguous. op=start/run only.
viewNoWhat to read. Default "hitlist". One of: hitlist, db, tree. op=read only.
depthNoMax call-tree depth relative to the traced object's own entry node. Default 4, max 12. op=read view=tree only.
objectNoClass or report to trace. Required for op=start and op=run.
aggregateNoAggregate repeated calls (no call tree afterwards). Default true. op=start/run only.
db_eventsNoRecord database events. Default true. op=start/run only.
sql_traceNoRecord SQL statements. Default true. op=start/run only.
executionsNoHow many executions the request stays armed for, default 1, max 5. op=start only — op=run always arms a single execution.
descriptionNoShort label for the trace request (max 60 chars). op=start/run only.
max_secondsNoTrace duration cap in seconds. Default 600, max 1800. op=start/run only.
max_size_kbNoTrace file size cap in KB. Default 30720, max 102400. op=start/run only.
internal_tablesNoRecord internal-table operations. Default false. op=start/run only.
procedural_unitsNoRecord procedural units (FORM/FUNCTION/METHOD calls). Default true. op=start/run only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.25
    • changedInput schema / properties / depth / description
      Previous value: -"Max call-tree depth, relative to the traced object's own entry node (that node is depth 0), not the ADT dispatch root. Default 4, max 12. op=read view=tree only."New value: +"Max call-tree depth relative to the traced object's own entry node. Default 4, max 12. op=read view=tree only."
    • changedInput schema / properties / executions / description
      Previous value: -"How many executions the request stays armed for. Default 1, max 5. op=start only — op=run always creates a single-execution request."New value: +"How many executions the request stays armed for, default 1, max 5. op=start only — op=run always arms a single execution."
    • changedInput schema / properties / id / description
      Previous value: -"A trace run id (op=read) or a trace run/request id (op=delete). Accepts either the bare id or the full path a previous list/create answered with."New value: +"A trace run id (op=read) or run/request id (op=delete); bare id or the full path a previous list/create answered with."
    • changedInput schema / properties / root / description
      Previous value: -"Anchor the tree view at the first call-tree node whose description or calling-program name matches this text (case-insensitive substring; matched uppercased). Overrides the automatic anchor, which is the traced object's own entry node. op=read view=tree only."New value: +"Anchor the tree view at the first call-tree node matching this text (case-insensitive substring on description or calling-program name), overriding the automatic entry-node anchor. op=read view=tree only."
  2. Addedv0.6.2

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag this as destructive (destructiveHint=true) and not read-only, and the description adds meaningful behavior: op=delete removes runs/requests, op=start arms a request, and op=run traces and reads back results. It covers the key side effects beyond what the annotations alone state.

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 compact, information-dense, and front-loaded: it states the core purpose first, then cleanly maps each operation to its effect. There is no filler, and every clause earns its place.

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?

Given the tool's complexity (5 operations, 18 parameters, no output schema), the description covers the operation semantics well and even notes defaults like op=run. It does not describe the exact shape of results or prerequisites beyond what the schema already provides, but for selecting and invoking the tool it is largely complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description enriches the op parameter by explaining what each operation does, but it does not add meaning for the many other parameters, which are already well-documented in the input schema.

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 description opens with a specific resource, ABAP runtime tracing (SAT), and a clear action: recording time per call and database access for a request's dispatch. It then enumerates each operation (run, start, list, read, delete) with concrete effects, making the tool's purpose obvious and distinguishing it from generic ABAP read/run/debug siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear within-tool guidance for choosing among operations, such as using op=start to arm a later trace versus op=run to trace immediately. However, it does not address when to choose abap_trace over sibling tools like abap_run, abap_debug, or abap_test, nor does it state exclusions or alternatives.

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