Skip to main content
Glama
ClementRingot

ADAM

by ClementRingot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Read active ABAP source with line numbers

abap_source
Read-onlyIdempotent

Retrieves active ABAP source with debugger line numbers for classes, programs, function modules, includes, CDS views, behavior definitions, and service bindings; filter by method, line range, or grep.

Instructions

The ACTIVE source with its line numbers: of a class (main source or a local-class include), a program or a function module — numbered as abap_debug breakpoints use them — and of interfaces, includes, CDS views, behavior and service definitions. A service binding (SRVB) shows its service definitions: from a Fiori app's binding, follow SRVD → CDS views → BDEF → behavior pool to the code to debug. Narrow a source with method, lineStart/lineEnd or grep.

Input Schema

NameRequiredDescriptionDefault
grepNoCase-insensitive regular expression: only matching lines (and one line around each) are returned.
nameYesObject name.
typeYesCLAS, PROG or FUNC (where breakpoints go); INTF, INCL, DDLS (CDS view), DCLS, DDLX, BDEF (behavior definition), SRVD (service definition) or SRVB (service binding: its service definitions) to follow a Fiori app to its code.
methodNoCLAS only: just this method (get_total, zif_order~process, lhc_travel~validate_dates), numbered as in the whole source.
includeNoCLAS only: a local-class include instead of the main source — implementations (local classes, e.g. RAP handlers lhc_*), testclasses (ABAP Unit), definitions (local types). Detected for lhc_/lcl_/ltc_ methods.
lineEndNoLast line to return.
lineStartNoFirst line to return (1-based).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent and non-destructive behavior, and the description adds meaningful context beyond them: only ACTIVE source is returned, line numbers match abap_debug breakpoints, and SRVB returns its service definitions. It does not discuss error behavior for inactive or missing objects, but the active-only and line-number semantics are valuable.

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 appropriately sized and front-loads the core resource. The first sentence is somewhat convoluted due to the colon-and-dash construction, but the later sentences add useful usage and parameter context without excess.

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?

For a seven-parameter read tool with full schema coverage and annotations, the description supplies the critical behavioral context: active-only source, supported object types, line-number alignment, and the SRVB/Fiori follow chain. It could say more about return shape or missing/inactive object handling, but 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 coverage is 100%, so parameter meanings are already well documented in the input schema. The description reinforces that method, lineStart/lineEnd and grep narrow the source and mentions the abap_debug line-number convention, but adds little beyond the structured parameter definitions.

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 clearly identifies the resource: ACTIVE ABAP source for classes, programs, function modules, interfaces, includes, CDS views, behavior definitions, service definitions and bindings. It adds a useful qualifier, line numbers aligned with abap_debug breakpoints, but does not explicitly distinguish itself from siblings such as abap_search.

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?

Usage is implied through the Fiori debugging flow and the suggestion to narrow source with method, lineStart/lineEnd or grep. However, it does not explicitly say when to use abap_source instead of abap_search or abap_debug, so an agent must infer the boundary.

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