An ABAP MCP Server That Doesn’t Depend on ADT

One MCP server for every ABAP system you run — from SAP ECC 6.0 to S/4HANA on-premise and S/4HANA private cloud edition. Most ABAP MCP servers are wrappers around the ADT REST API. ABAPilot runs as in-system ABAP on native ICF handlers, with purpose-built tools, an endpoint whitelist you control, and a full audit trail. No ADT. No Eclipse. No BTP. No RISE commitment.

Request a demo  ·  Inspect the open-source connector on GitHub

The ADT dependency is not a detail — it is the boundary

Almost every community ABAP MCP server built so far speaks to SAP through the ADT (ABAP Development Tools) REST API. It is a sensible engineering choice: ADT is documented, it is what Eclipse already uses, and it makes a working server possible in days.

It also inherits ADT’s limits. A server that talks ADT can only reach systems where the ADT services are installed, activated and exposed to the caller — and that is a genuine variable across a real landscape. Older ECC installations may never have had them switched on. Basis teams routinely leave ADT services deactivated in production, because ADT is a development surface and production is not for development. Where ADT is unavailable, an ADT-based MCP server is not degraded — it is simply unusable.

ABAPilot takes the other route. It is a pure-ABAP add-on delivered by transport into a customer-owned namespace, exposed through a single ICF node. Its dependency is the ABAP stack itself. If the system runs ABAP and you can import a transport into it, ABAPilot runs there.

Where each approach runs

Being on RISE does not exclude you. Private cloud edition customers who can transport into their own stack can run ABAPilot. Public cloud and ABAP Cloud are the honest exception — that extensibility model rules out an in-system add-on of this kind, and we would rather say so here than in your first technical call.

Purpose-built tools beat a generic API wrapper

Wrapping ADT gives a model everything ADT can do — create objects, activate them, manage transports — whether or not the task calls for it. ABAPilot exposes a deliberately small, named set of read-oriented tools, each shaped around a job someone actually needs done:

• sap_read_table_data — any table, any WHERE clause, row limit enforced
• sap_read_table_structure — fields, types, keys
• sap_search_tables — find the right table by keyword
• sap_read_code — source of programs, classes, function modules
• sap_read_where_used — impact analysis before a change
• sap_syntax_check — validate generated ABAP against the real system
• sap_read_dumps — ST22 runtime errors
• sap_read_jobs — background job status and failures

Three practical consequences. Business data is in scope. ADT is a development interface; it was never meant to answer “which vendors have open invoices over €50,000”. A tool built for table reads answers it directly, which is why ABAPilot serves finance and audit users, not only developers. Responses are compact. ADT returns XML designed for an Eclipse client; wrapping it means the model parses verbose markup and you pay for those tokens on every call. Typed, purpose-shaped responses cost less and are read more reliably. Fewer tools select better. Tool-choice accuracy degrades as the catalogue grows; eight well-named tools produce fewer wrong turns than several dozen generic ones.

The surface you expose is the surface you have to defend

This is the question that decides enterprise deployments, and it is worth being precise about. A generic wrapper inherits the whole capability set of the API it wraps, and the only thing standing between that capability and your production system is the model’s judgement plus whatever the connecting user happens to be authorised for.

ABAPilot narrows it deliberately, in your system, under your control:

• Named-user execution. Every call runs under a real SAP user’s own authorisations — S_TABU_DIS, S_DEVELOP and the rest enforced by the standard authorisation model, not reimplemented. If you cannot see it in SAPGUI, you cannot see it through ABAPilot.
• Endpoint whitelist. A whitelist table defines exactly which operations exist. Anything outside it is unreachable — a hard boundary maintained by your Basis team, not by prompt instructions.
• Execution policy and full audit trail. Read-only by default, and every request written to an in-system audit log with user, timestamp and parameters — the evidence an internal auditor asks for.
• Model of your choice. Claude, OpenAI, Gemini or Bedrock with your own key — or a fully local model via Ollama, so no data leaves your network at all.

Open where it matters, commercial where the product is

A fair question from any developer: why not open-source the whole thing?

Our answer is to open the part that touches your credentials. The ABAPilot MCP connector is MIT-licensed and public — you can read every line that handles your system’s connection before you point it at anything, and the architecture document describing the four control gates is published alongside it. Installation is a single npx command.

The in-system ABAP engine is the licensed product: the ICF handlers, the whitelist and policy layer, the audit log, the query planning. It ships as a transport into your own namespace, it stays inside your system, and it is supported.

We think that split is the honest one. Nobody should have to trust an opaque binary with an ERP connection — and the thing that connects to your ERP is exactly the part we made inspectable.

Which one should you use?

Genuinely, it depends on the job — and several of the community ADT servers are good work by people who care about this ecosystem.

An ADT-based server is a good fit if you are a developer working in a modern system where ADT is active, you want to create and activate objects and drive transports from your IDE, and code authoring is the whole use case.

ABAPilot is the better fit if any of the following are true: your landscape includes older ECC systems, ADT is deactivated in the systems that matter, you need business data and not just source code, non-developers will be asking the questions, or your security review requires a whitelist, named-user execution and an audit trail inside SAP.

They are not mutually exclusive. Several teams run an ADT server for authoring and ABAPilot for data access, analysis and everything outside the development client.

See also: ABAPilot vs SAP’s own ABAP MCP Server and AI for SAP ECC — the 2026 guide.

Frequently Asked Questions

Do I need ADT or Eclipse to run ABAPilot?

No. ABAPilot is a pure-ABAP add-on exposed through a native ICF node in a customer-owned namespace. It does not call the ADT REST API and does not require ADT services to be installed or active, so it runs on systems where ADT-based MCP servers cannot.

Which SAP systems does ABAPilot support?

Any ABAP-based instance you can import a transport into: SAP ECC 6.0 and above, S/4HANA on-premise, and S/4HANA private cloud edition, including RISE customers running private edition. S/4HANA public cloud and ABAP Cloud are not supported, because that extensibility model does not permit an in-system add-on of this kind.

Does being on RISE with SAP exclude me?

Not if you are on private cloud edition and can import your own transports — ABAPilot runs there. Public cloud edition is the exception.

Is ABAPilot open source?

The MCP connector is open source under the MIT licence and published on GitHub, together with its architecture and security documentation, so you can inspect everything that handles your system connection. The in-system ABAP engine is the licensed commercial product.

How is access controlled compared with a generic ADT wrapper?

Every request executes under the SAP user’s own authorisations, an endpoint whitelist table defines exactly which operations exist, execution policy is read-only by default, and every call is written to an in-system audit log. The exposed surface is a small set of named tools rather than the full capability of a wrapped development API.

Run AI on the SAP systems you actually have

ECC 6.0, S/4HANA on-premise or S/4HANA private cloud — deployed by transport, inspectable before you connect it, auditable after.

Request a demo