Every tool starts with Get or Search — nothing activates, transports or writes — so a wrong call costs a read against the system and nothing else. The split of the tool set follows how ABAP is actually stored: a function module is retrievable separately from its group, an include separately from the program that uses it, which is what lets a model assemble the full picture from parts. Only one tool returns business data rather than code, and it caps rows rather than streaming them.
A read-only client for SAP's ABAP Development Tools services, retrieving source and dictionary objects from one system and client over its ADT endpoints.
- Source for every container a change usually spans: programs, classes, interfaces, includes, function groups and individual function modules
- Dictionary objects on their own terms — structures, table definitions and type information
- Actual table contents with a row cap, not only the definition
- RAP artefacts where the system supports them: behaviour definitions and service definitions as source
- CDS views returned as DDL source
- Object discovery through a quick search with a result cap, plus package details and transaction details
Node and four values for the system you are pointing at: SAP_URL, SAP_USERNAME, SAP_PASSWORD and SAP_CLIENT, with SAP_LANGUAGE optional. Two things on the SAP side decide whether it answers at all: the /sap/bc/adt service has to be active in SICF, and the user needs the authorizations for ADT. A system behind a self-signed certificate needs TLS_REJECT_UNAUTHORIZED set. Behaviour and service definitions need roughly NetWeaver 7.54 or S/4HANA; on older systems those objects do not exist to fetch. MIT.
One command plus a key — npx -y mcp-abap-adt, then supply credentials