abap-config-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SAP_URL | Yes | Base URL of the SAP system's ADT service, e.g. https://host:44300 | |
| SAP_USER | Yes | SAP user to log on with; the server can do nothing beyond this user's authorizations | |
| SAP_CLIENT | No | SAP client, e.g. 100 | |
| SAP_LANGUAGE | No | Logon language (default EN) | |
| SAP_PASSWORD | Yes | Password of the SAP user | |
| ABAP_NO_WARMUP | No | 1 to skip the background logon at startup | |
| ABAP_MCP_MAX_TIER | No | Highest tool risk tier to register: 0 read-only, 1 governed customizing, 2 or unset full development surface | |
| SAP_ALLOW_SELF_SIGNED | No | true to accept a self-signed certificate (common on development systems) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connected_systemsA | List the SAP systems this server is configured for: connection id, URL, user and client, with the default connection marked. Call this first when more than one system is configured, and pass the id as connectionId to any other tool. SOAP RFC connections are flagged as read-only (tables and sources only, no ADT). Only reads local configuration; does not contact SAP or log in. |
| search_abap_objectsA | Search ABAP repository objects by name or wildcard pattern and return type, name, description and ADT URL for each hit. Use it to find the URL that get_abap_object_lines, write_abap_object_source or where_used need; use browse_package to list a package instead, search_abap_object_lines to search inside source, and search_database_tables for tables by keyword. Read-only; at most maxResults hits (default 50). |
| get_abap_object_infoA | Read an ABAP object's metadata from its ADT URL: name, type, description, responsible user, language, version and URL, plus its includes for objects that have them (e.g. classes). Does not return source code; use get_abap_object_lines for that and get_transport_for_object for transport and lock state. Read-only. Find the URL with search_abap_objects. |
| force_reloginA | Drop this conversation's SAP ADT session and log in again. Use when ADT calls keep failing with HTTP 400 (degraded stateful session) and the automatic retry has not recovered it. Releases this conversation's locks only — every conversation has its own SAP session. |
| adt_discoveryA | List the ADT services the SAP system exposes, each with its collection titles or hrefs, from the ADT discovery document. Use it to check whether a feature (for example a data preview or ATC endpoint) exists on this release before relying on a tool that needs it, or when a tool fails with 404. Read-only; takes no object input and returns a plain list, which can be long. |
| get_abap_object_linesA | Return the full ABAP source text of one object (program, class, function module, include, ...). Give the object URL and /source/main is appended automatically if you omit it. Use search_abap_object_lines to find a pattern instead of reading everything, get_abap_batch_lines for several objects at once, and get_abap_object_info for metadata only. Read-only; returns the stored version as one string, with no line numbers. |
| search_abap_object_linesA | Find lines in one object's source that match a case-insensitive regular expression and return them as numbered lines (line number, then text). Use it to locate a statement before editing or setting a breakpoint; use where_used for references across objects and get_abap_object_lines to read the whole source. Read-only; searches a single object per call and reads the full source first. |
| get_abap_batch_linesA | Return the source of several ABAP objects in one call, each under a header line with its URL. One failing URL is reported as an error entry and does not stop the others. Use get_abap_object_lines for a single object. Read-only; the combined text can be large, so batch only what you need. |
| syntax_checkA | Run the SAP syntax check on source text you supply, in the context of an existing object, without saving or locking anything. Returns each message as line:column, severity and text, or a no-errors confirmation. Use it before write_abap_object_source; use run_atc_analysis for quality checks on the saved object. Read-only; the object must already exist. |
| write_abap_object_sourceA | Write/update the source code of an ABAP object: locks, writes, reads back to verify, and releases the lock (keepLock: true to keep it). Give the code as source, or — for large sources — sourcePath, an absolute path to a local file under your home directory (UTF-8, at most 5 MB) that is sent as it is; exactly one of the two. The new source is the inactive version until abap_activate. Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation. |
| lock_abap_objectA | Take an exclusive edit lock (enqueue) on an ABAP object and return the lock handle; the lock belongs to this conversation's SAP session and blocks other users from changing the object. Rarely needed: write_abap_object_source locks and unlocks by itself, and abap_activate releases a held lock. Use it only to keep an object locked across several calls, and release it with unlock_abap_object. Fails if another user or session already holds the lock. |
| unlock_abap_objectA | Release the edit lock this server holds on an ABAP object, taken by lock_abap_object or kept by write_abap_object_source with keepLock. Saved (inactive) source is not removed. Use it to free an object you will not activate; abap_activate releases a held lock itself. If this server holds no lock and no handle is given, nothing is released and the call explains why; force_relogin drops the whole session's locks as a last resort. |
| create_abap_objectA | Create a new ABAP development object (program, class, function group, include, table, etc.) in a package. A local package ($TMP) needs no transport. Creating a function group include (FUGR/I) also adds its INCLUDE line to the group's main program — do not add it again. Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation. |
| delete_abap_objectA | Delete an ABAP repository object from the SAP system and record the deletion on a Workbench request (not needed for a local $ package). Irreversible. The tool locks the object, deletes it and unlocks it. Check where_used first, since other objects may still reference it. Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation. |
| abap_activateA | Activate an ABAP object — compiles it and makes it executable (equivalent to F8/Activate in the ABAP workbench). If the object is currently locked by a prior write_abap_object_source or set_text_elements call, the lock is released automatically before activation. The object must have been written/saved first. |
| abap_activate_multipleA | Activate several inactive ABAP objects in one call. Only URLs that match the inactive worklist (check_inactive_objects) are activated; others are skipped, and if none match nothing happens. Releases any lock this server holds on them first. Reports success or failure with messages, and warns when SAP says success but an object is still inactive. Use abap_activate for a single object. |
| run_atc_analysisA | Run an ABAP Test Cockpit (ATC) check on one object and return each finding as priority, check title and id, message, and object with line number, or a pass message when there are none. Use syntax_check for a quick compile check of unsaved source and run_unit_tests to execute tests. Starts an ATC run on the SAP system for the object; changes no object. Needs ATC authorization and a variant that exists in the system. |
| run_unit_testsA | Run the ABAP Unit test classes of an object and report each test method as passed or failed with its alert details, plus a total. A class with no method results is reported as unknown, not passed. By default runs all risk levels and durations; narrow with riskLevels and durations. Executes the test code on the SAP system, which can change data if the tests do; use abap_run_class to run a console class instead and run_atc_analysis for static checks. |
| abap_run_classA | Run a class that implements IF_OO_ADT_CLASSRUN (ADT's 'Run as ABAP Application (Console)') and return what its MAIN method wrote to OUT. Runs the class's current active version, in a session of its own. The class decides what happens — it can post documents and commit — so read it before running it. Never retried automatically after a lost session. A run that takes longer than waitSeconds keeps running in SAP and answers with a runId: call again with runId to wait for it and get the output. |
| create_test_includeA | Create the local test include of an existing class so local test classes can be added to it; it adds no test code itself. Write the tests afterwards with write_abap_object_source, activate, then run them with run_unit_tests. The tool locks the class, creates the include and unlocks it again, and records the change on a Workbench request (not needed in a local package). Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation. |
| manage_transport_requestsA | Work with one transport request at a time through action: list (a user's open requests), details (header, tasks and objects of a request), create, release, delete, change_owner. release exports the request and cannot be undone; delete fails while SAP still holds object locks on it; create and change_owner change the CTS. Use list_all_transports to see other users' requests, get_transport_for_object for the request an object needs, and transport_move to move objects between requests. Needs CTS authorization (S_TRANSPRT). |
| list_all_transportsA | List transport requests of all users (or one owner), grouped by owner and newest first: number, kind, status, date, description, the piece of work it is remembered for, and optionally its objects including its tasks' objects. Reads the CTS tables E070, E07T and E071 with SQL through ADT, so it needs table read authorization (S_TABU_DIS). Use manage_transport_requests with list for one user's open requests and details for a single request. Read-only; at most 500 requests, objects for the newest 100. |
| get_transport_for_objectA | Report how a change to an ABAP object is transported: its package, whether recording is needed (a local $ package needs none), the request it is already locked into, and the open requests the transport layer allows. Use it before write_abap_object_source or delete_abap_object to pick a transport; list_all_transports shows open requests generally. Read-only; takes no lock and creates no request. |
| transport_moveA | Move object entries from one transport request/task to another, or reassign a whole task to another request — with the checks a careful Basis colleague makes first. DRY RUN by default: shows the plan, runs SAP's own test move (TR_MOVE_OBJECTS test mode), and reports what the moved objects use and are used by on other open requests, with the release order that follows. commit: true moves and verifies in E071. objects given → those entries move ("R3TR CLAS ZCL_X", "CLAS ZCL_X", "ZCL_X", "ZCL_FOO*"); an object's parts (methods, sections, includes, function modules) move with it unless includeParts: false. no objects, from = a task → the whole task moves to the target request (TR_REASSIGN_TASK). Stops before SAP is called when a request is released, the kinds differ (Workbench/Customizing), or the clients differ; warns when the target goes to another system or an object would be split. |
| execute_data_queryA | Run one freestyle SELECT (ABAP SQL, as in the ADT data preview) against dictionary tables or CDS views and return the rows as an aligned text table or JSON. Statements containing INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, EXEC, EXECUTE, TRUNCATE or MERGE are rejected, and the query must start with SELECT. Use read_table_contents for a plain table read and describe_database_table to learn the field names. Needs data preview and table read authorization (S_TABU_DIS); returns at most maxRows rows. |
| read_table_contentsA | Read the rows of one ABAP dictionary table or view by name, optionally filtered with a WHERE clause, up to maxRows. Use it for a quick look at one table; use execute_data_query for joins, selected columns, aggregates or ORDER BY, describe_database_table for the field list, and customizing_read for a customizing table filtered on one key field. Read-only. The optional whereClause filter requires the ADT Data Preview service (SICF node /sap/bc/adt/datapreview, SAP_BASIS ≥ 7.40 SP08) to be active. If whereClause returns an error, use execute_data_query with a full SELECT ... WHERE ... UP TO n ROWS statement instead — that uses a different ADT endpoint and works on all supported SAP versions. |
| where_usedA | List where an ABAP object, or a symbol inside it, is used (the where-used list). Returns each usage as a location with a source snippet when SAP provides snippets, otherwise as name, type and URL. For symbol-level search pass line and column of the symbol in the object's source. Use search_abap_object_lines to search text inside one object instead. Read-only. |
| version_historyA | List the stored revisions of an ABAP object, one line per revision: version id, date, author and version title. Lists metadata only, not the source of each version. Use it to see who changed an object and when; use get_transport_for_object for its current transport. Read-only. Returns a no-history message for objects without revisions. |
| analyze_dumpA | List ABAP runtime dumps (the short dumps shown in ST22) from the SAP system: category, short text, dump id and user. Lists them only; it does not return the dump text or stack. Use it to find a failing run after abap_run_class or run_unit_tests, then open the dump in ST22. Read-only; the optional query narrows the feed. |
| check_inactive_objectsA | List ABAP objects with an inactive version (saved but not activated): type, name and ADT URL, for the connected user's inactive worklist. Use it after write_abap_object_source to find what still needs activating, then pass the URLs to abap_activate or abap_activate_multiple. Read-only; takes no object input. |
| abap_debug_sessionA | Start, check or end the external ABAP debugger listener for a user. 'listen' registers a listener and then blocks until a program of that user hits a breakpoint (set one first with abap_debug_set_breakpoint) or the listener times out, and returns the debuggee details; then use abap_debug_step, abap_debug_variable and abap_debug_stack. 'status' shows the listener this server holds for the connection; 'detach' removes it. Reports a conflict if another debugger is already attached for that user. Does not change any object. |
| abap_debug_set_breakpointA | Set an external breakpoint on one source line for a user. Returns the breakpoint id (or an error entry), which abap_debug_delete_breakpoint takes. Set breakpoints before abap_debug_session with action listen, then run the program as that user to trigger it. Registers the breakpoint in SAP for that user; it does not change the object's source. |
| abap_debug_delete_breakpointA | Remove one external breakpoint by the id abap_debug_set_breakpoint returned. Use it when a breakpoint should no longer stop the program; it does not end a running debug session (use abap_debug_session with detach, or abap_debug_step with terminateDebuggee, for that). Removes the breakpoint registration in SAP only; source is untouched. |
| abap_debug_stepA | Execute one debugger step in the active session and return the new position as JSON. stepInto, stepOver and stepReturn move one step; stepContinue runs on to the next breakpoint or to the end; terminateDebuggee ends the debugged program. Needs a debuggee stopped at a breakpoint, which abap_debug_session with action listen delivers. Changes the running program's state, so it cannot be undone. |
| abap_debug_variableA | Read the current values of named variables in the stopped debuggee, one line each as NAME (type) = value. Use abap_debug_stack first to see which frame you are in, and abap_debug_set_variable to change a value. Read-only; needs an active session stopped at a breakpoint (abap_debug_session with action listen). |
| abap_debug_stackA | Return the call stack of the stopped debuggee as JSON (the stack entries ADT reports). Use it after a breakpoint hit to see where you are before stepping or reading variables with abap_debug_variable. Read-only; needs an active session stopped at a breakpoint (abap_debug_session with action listen). |
| abap_debug_set_variableA | Overwrite a variable in the stopped debuggee and return the value SAP reports back. Affects only the running program's memory for this debug session, not the database or source, but whatever the program does afterwards uses the new value. Needs an active session stopped at a breakpoint; check the current value first with abap_debug_variable. |
| get_text_elementsA | Read text elements for an ABAP program, function group or class: selection texts (PARAMETERS / SELECT-OPTIONS labels, flagged when they are dictionary references), text symbols (TEXT-001 etc., with their maximum length), and list headings (LISTHEADER, COLUMNHEADER_1..4). Omit category to retrieve all three. |
| set_text_elementsA | Write text elements for an ABAP program, function group or class, in the format SAP requires. • selections — selection-screen texts for PARAMETERS / SELECT-OPTIONS. Set dictionaryReference: true to take the text from the data element (the SE38 'Dictionary ref.' box); text may then be empty and SAP fills it. Own texts max 30 characters. • symbols — TEXT-xxx, ids of 3 characters. Every symbol is written with a maximum length (maxLength, default the text's length); SAP rejects symbols without one. • headings — LISTHEADER (max 71) and COLUMNHEADER_1..COLUMNHEADER_4 (max 255). Writes MERGE by default: listed ids are added or updated, everything else is kept (the underlying ADT write replaces the whole category, so the tool reads first). Use remove to delete ids, or replace: true to write exactly the list. Returns what SAP stored, then activates the text elements (activating the program alone does not; pass activate: false to leave them inactive). |
| browse_packageA | List the objects directly inside an ABAP package, grouped by object type, with name and description (at most maxObjects per package). Sub-packages appear as entries of type DEVC/K; includeSubPackages also lists the contents of those one level down. Use it to explore a package; use search_abap_objects to find an object by name across packages. Read-only. |
| create_packageA | Create a new ABAP package (DEVC) under an existing parent package and return its settings. Writes to the repository and is recorded on a Workbench request; the transport is chosen as described for write_abap_object_source, and a local package ($TMP) needs none. Add objects afterwards with create_abap_object. Needs development authorization (S_DEVELOP) and a software component and transport layer that exist in the system. |
| search_database_tablesA | Find database tables and views by keyword when you do not know the technical name, via the ADT object search for types TABL and VIEW. Returns kind, name, package and description per hit, sorted by name, for standard, industry and Z/Y objects alike. Follow with describe_database_table for the fields, then read_table_contents or execute_data_query for the rows; use search_abap_objects for other object types. Read-only; maxResults applies to tables and views separately. |
| describe_database_tableA | Show all field names, types, lengths, and descriptions for a SAP database table or view. Key fields are marked with 🔑. Use this after search_database_tables to understand the structure before querying, so you know which fields to filter or select. |
| img_searchA | Search the SAP Implementation Guide (IMG / SPRO) for customizing activities by keyword, using the IMG index (CUS_IMGACT activity titles) joined to the maintenance object. Returns activity IDs, SPRO titles, maintenance objects, and their pattern (V=view→VDAT, S=table→TABU, C=cluster→CDAT, T=transaction, D=doc). Pass |
| customizing_describeA | Describe a SAP customizing view or table: underlying base table, all fields with key markers, delivery class (transport behaviour), authorization group (S_TABU_DIS), maintenance program, and foreign-key references on key fields (org-unit candidates). Use after img_search to understand the structure before reading or changing config. |
| customizing_readA | Read the current rows of a customizing table or maintenance view (a view is resolved to its base table) as an aligned text table, optionally filtered to rows where one key field equals one value. The filter applies only when both keyField and keyValue are given. Use customizing_diff to compare two org units, customizing_describe for the field list, and read_table_contents for non-customizing tables. Read-only; needs table read authorization (S_TABU_DIS); returns at most maxRows rows. |
| customizing_diffA | Compare customizing configuration for a table/view between two org-unit key values (e.g. plant 1000 vs plant 2000, or company code DE01 vs AT01). Shows rows present in source but missing from target, and vice versa. Use customizing_plan_change to generate the insert plan for the missing rows. |
| customizing_plan_changeA | Preview, from ADT reads alone, the rows that copying customizing from one org-unit key to another would insert (e.g. plant 1000 to a new plant 2000), with the maintenance view, delivery class and transport object. Nothing is written and the in-system engine is not needed, so it works before the engine is installed. Use it for a quick look at one table; for the plan of the write you will actually run, use customizing_apply without commit (its dry run goes through the engine and the SM30 runtime), and org_copy for a whole org unit across all its tables. |
| customizing_engine_bootstrapA | Install or update the Customizing Engine in the SAP system: creates or overwrites the class ZCL_MCP_CUST_ENGINE and the batch writer report ZMCP_CUST_WRITE, writes their source and activates both. Run it once to install and again when the engine version changes; the first install then needs a one-time SICF service registration (handler ZCL_MCP_CUST_ENGINE), which the result spells out. Use it to update the engine in place (default package $TMP); for a first setup, or to make the engine transportable, use engine_deploy instead, which calls this and also registers SICF. The customizing tools with autoDeploy update the engine themselves, so this is rarely needed. Verify with customizing_engine_ping; remove with customizing_engine_cleanup. Writes repository objects and needs development authorization (S_DEVELOP). |
| customizing_engine_pingA | Call the Customizing Engine's SICF endpoint with a ping and report the deployed version against the version this server expects, plus the release, client and which engine features the system offers. Use it to confirm customizing_engine_bootstrap worked and the SICF service is active; a version mismatch means run bootstrap again. Read-only: changes nothing in SAP. On failure, retry with rawDump to see the raw HTTP response. |
| hana_memory_reportA | Diagnose HANA memory pressure on the tenant this ABAP system runs on, via the Customizing Engine's SICF endpoint (ADBC over SYS.M_* monitoring views — read-only). Reports host RAM/swap, per-service usage, top heap allocators, the largest loaded column tables, row store, SQL plan cache, and the configured global_allocation_limit. Use when the system is slow/swapping or before resizing. Needs engine v0.9.8+ (run customizing_engine_bootstrap to update). |
| abap_memory_reportA | Report the ABAP application server's key kernel memory / box-health profile parameters (PHYS_MEMSIZE, em/initial_size_MB extended memory, abap/heap_area_*, ztta/roll_*, abap/buffersize, work-process counts) via C_SAPGPARAM — basis-only, so it works on any ABAP box. Companion to hana_memory_report: on a single-host AS+DB appliance, read BOTH and check that HANA global_allocation_limit + ABAP working memory + OS ≤ physical RAM (over-commit shows up as swap). Needs engine v0.9.16+. |
| org_copyA | Copy or delete a WHOLE organizational unit including all its dependent customizing, via SAP's standard entity copier (ECOP_ORG_UNITS_IN_THE_DARK) — the exact engine behind EC01/EC02/EC04…, run headlessly through the in-system Customizing Engine. orgUnit values (org-key DOMAIN): BUKRS company code (EC01), WERKS plant (EC02), CACCD controlling area (EC03), VKORG sales org (EC04), VTWEG distribution channel (EC05), SPART division (EC06), VSTEL shipping point (EC07), LGNUM warehouse no. (EC09), EKORG purchasing org (EC13), LGORT storage location (EC14), MTART material type (EC15). DRY RUN by default: lists the copier's dependent tables, then the RETEST SCOPE — every customizing table (delivery class C/G/E) keyed on the org domain that the copier does NOT copy, with live source/target row counts (source has rows, target none = retest first), and a summary of application/master-data tables (class A) keyed on it. Run the dry run again after the copy, same source and target, to diff the new unit against the source. commit: true performs the copy and commits. TRANSPORT: the entity copier records onto a Customizing request it MINTS ITSELF and reports back — it cannot record into a request you supply (a passed transport is ignored). On commit set createTransport: true to acknowledge that; the copier names the request. The copier never overwrites: it fails if the target unit already exists. After the copy, patch unit-specific values (name, currency, country, …) with customizing_apply using values + onlyMissing: false. Needs engine v0.9.9+. |
| customizing_applyA | Copy or delete customizing rows through the in-system engine, which drives the SM30 maintenance-view runtime (VIEW_MAINTENANCE_SINGLE_ENTRY) so FK checks, events, change docs and transport recording all run the standard way. DRY RUN by default — returns the exact rows affected. Set commit: true to apply. Use it for one table or view; use org_copy to copy a whole org unit, customizing_create for new rows with no source row, and customizing_plan_change for a quick preview without the engine. action: "copy" (default) — duplicate rows from sourceKey to targetKey. action: "delete" — remove the entry whose keyField = targetKey (sourceKey not needed), recording the deletion onto the transport like an SM30 delete. Delivery class behaviour: C / G / E — customizing + control tables: transport-based write. Provide a transport when committing. A — application data (e.g. /POSDW/STORE): direct MODIFY + COMMIT, no transport recording (copy only). Do NOT pass a transport for class-A tables. The engine enforces S_TABU_DIS authorization on the target table. |
| customizing_createA | Create new customizing rows from explicit field/value maps — full keys (including COMPOSITE keys) and distinct per-row values, with NO source row to copy from. This is what customizing_apply (a single-key copy) can't express: e.g. storage locations T001L (key WERKS+LGORT) each with their own LGOBE description. Each entry in DRY RUN by default — returns the planned rows. Set commit: true to write. onlyMissing (default true) skips rows whose key already exists — idempotent create. recordTransport: false → direct write, no transport (sandbox/test data); omit transport then. Delivery class C/G/E records onto a Customizing request (provide transport or createTransport); class A writes directly. Enforces S_TABU_DIS on the table. |
| retail_listingA | List one or more articles into retail assortments via SAP's standard listing engine (EXECUTE_LISTING_ART_ASSORT_RFC, determine_data=X). Listing EXTENDS each article to the assortment's assigned sites (creating the plant/valuation segments) and writes the WLK1 listing conditions, so the article becomes available at those sites. Listing into a GENERAL assortment propagates to all its assigned sites (incl. their local assortments). DRY RUN by default — returns the prepared listing items. Set commit: true to execute. dateFrom/dateTo default to today / 9999-12-31. Material numbers are ALPHA-padded automatically. |
| customizing_statusA | Check the result of an asynchronous customizing write (customizing_apply with commit: true) by its run_id. The write runs in a background job for headless transport recording; if it doesn't finish within apply's poll budget, apply returns a run_id — use this tool to poll until it reports ok/error. |
| customizing_selftestA | Non-destructively validate the engine's risky internals — dynamic table typing, sample read, flat TABKEY construction, and (if a transport is given) TR_OBJECTS_INSERT in SIMULATION mode — without writing data or recording any transport. Auto-deploys the engine class if needed. Run this after the first bootstrap to confirm the write path will work before any real commit. |
| customizing_engine_cleanupA | Delete the Customizing Engine class ZCL_MCP_CUST_ENGINE from the SAP system. Without confirm: true it only shows what would happen and changes nothing. The report ZMCP_CUST_WRITE and the SICF service node are not removed; delete the node manually in SICF. Customizing tools that need the engine stop working until customizing_engine_bootstrap or engine_deploy installs it again. Use it only to remove the engine from a system; to update it, run customizing_engine_bootstrap. Deletion is irreversible and uses the same delete path as delete_abap_object. |
| engine_deployA | Install/manage the MCP's in-system ABAP, choosing per unit whether it is TRANSPORTABLE (created in a Workbench Z package on a transport, to be released to Production via CTS independent of the MCP) or deployed to $TMP (local, Dev-only). Run with NO unit to see the first-run setup prompt (or current status). Run per unit to deploy/flip: engine_deploy unit:"diag" transportable:true package:"ZMCP_DIAG" transport:"DEVK9…" engine_deploy unit:"cust" transportable:false Re-run any time to flip a unit (e.g. promote a higher-tier unit to transportable). Units: diag (Tier 0 read-only diagnostics) · cust (Tier 1 customizing engine). After a transportable deploy, register the unit's SICF node once (reported in the output). Which engine tool: engine_deploy for the first setup of a system and to choose or change where a unit lives (transportable or $TMP); customizing_engine_bootstrap only to install or update the customizing engine in place (the customizing tools also do that themselves via autoDeploy); customizing_engine_cleanup to remove it; customizing_engine_ping to check what is installed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 60 tools
Descriptions are unusually detailed and explicitly cross-reference neighbouring tools, separating overlapping areas such as read_table_contents vs execute_data_query vs customizing_read and customizing_engine_bootstrap vs engine_deploy. With 60 tools there is still some risk of confusion among the customizing, transport and object-lifecycle clusters, but the boundaries are well documented.
Most names are snake_case with recognizable verbs or noun phrases, but prefixes are inconsistent: get_abap_object_info and abap_activate coexist with where_used, version_history and syntax_check, while customizing_engine_bootstrap sits beside engine_deploy. The naming remains readable, but the mixed conventions make the surface less predictable than it could be.
At 60 tools the surface is far beyond a well-scoped MCP server, even for a broad ABAP development and customizing platform. The tools cluster into coherent domains, but the sheer count imposes a heavy selection and context burden on an agent.
Coverage is comprehensive: ABAP object search/read/write/create/activate/delete, locking, text elements, packages, transports, where-used, version history, syntax/ATC/unit testing, debugging, dumps, table queries, customizing operations, org-copy and engine deployment. Obvious lifecycle and diagnostic paths are represented with no major dead ends.