# vibing-steampunk (vsp): an ADT to MCP bridge for ABAP and AMDP work

> vsp is a Go binary that exposes SAP ADT resources, including the ABAP debugger, to MCP clients and a CLI. It is for teams that want AI-assisted ABAP editing without installing anything on the SAP server, and it is limited by what each system's ADT surface actually offers.

**oisee/vibing-steampunk** — vs-punk: ADT to MCP bridge - Vibe code in ABAP / AMDP

- Repository: https://github.com/oisee/vibing-steampunk
- Stars: 493 · Forks: 119
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/oisee-vibing-steampunk

## The gap vsp fills: ADT has the API, agents have no way to call it

SAP's ADT layer already exposes source read, write, activation, tests, and the debugger as HTTP resources. Eclipse drives them. Almost nothing else does, because the debugger in particular keeps its session in an ABAP roll area that is only reachable again through a sap-contextid cookie, and because a client that spreads a debug loop over independent HTTP calls loses the debuggee between calls. vsp is a Go binary that carries those resources to two consumers: an MCP server that Claude and other assistants can call, and a CLI with a dbg> prompt for scripted work. The README frames the target as any system with ADT enabled from 7.50 upwards, and adds the caveat that the available surface varies by release, with vsp compat reporting it per system: RAP needs S/4, AMDP needs HANA, and some ADT resources present on S/4 are absent on ERP. That caveat is the honest part of the pitch. This is not a uniform product across SAP releases, and the tool tells you so rather than pretending otherwise.

## How the bridge works: pinned sessions, ADT resources, nothing on the server

The mechanism is a session, held open. For the debugger, vsp opens a pinned classic-RFC conversation and uses it as the ABAP session itself, so the roll area stays alive for the whole loop and there is nothing to correlate between calls. The README states that eclipse drives the same resources Eclipse uses, naming /sap/bc/adt/debugger/listeners, /sap/bc/adt/debugger and /sap/bc/adt/debugger/stack, tunnelled through SADT_REST_RFC_ENDPOINT. No ICF service, no CSRF token dance, no WebSocket upgrade, and nothing installed on the server. Where there is no RFC channel at all, vsp adt debug runs the identical loop over one stateful HTTPS session, which the README says was verified against A4H with a cookie or a password and no gateway port. The repository layout matches that story: pkg/saprfc/ holds the RFC transport, and the integration test go test -tags=integration -run Conformance ./pkg/saprfc/ is described as running the same debug script over both transports and failing when they disagree about where the debuggee stopped. That conformance test is the most interesting design decision in the project, because it treats the two transports as one behaviour with two carriers rather than two features.

## Installing vsp and running a first debug session

The README points at vsp update as the way to fetch the release for your platform; it is described as verified against checksums.txt and renamed into place of the running binary. Building from source uses the Makefile, whose binary is named vsp and whose local build carries the platform in the name, with build/vsp as a link to it so that tool configs pointing at either name see the same file. Credentials come from a .env copied from .env.example, which is the default system used when vsp runs without --system. For multiple systems the README points at .vsp.json instead, and states the priority order as CLI flags, then environment variables, then .env, then defaults.

```bash
cp .env.example .env
# then set SAP_URL, SAP_USER, SAP_PASSWORD, and optionally SAP_CLIENT and SAP_LANGUAGE
```

The example file shows SAP_URL in the form http://your-sap-host:50000, with SAP_CLIENT defaulting to 001 and SAP_LANGUAGE to EN. SAP_MODE selects the tool surface: focused is documented as 81 essential tools and the default, expert as all 122. Safety switches in the same file include SAP_READ_ONLY, SAP_BLOCK_FREE_SQL, SAP_ALLOWED_PACKAGES and SAP_ALLOWED_OPS. Before trusting any of it against a real system, the README's own first step is the compatibility report, which tells you which features the target release actually supports.

```bash
vsp compat
```

A first debug session is then a short loop. The README gives this sequence, where ebp sets a breakpoint by object name and ADT resolves the URI, eclipse listens, attaches and shows the stack, and elocals reads the stopped frame's variables.

```bash
vsp rfc debug
dbg> ebp ZADT_DEBUG_LOOP 9
dbg> eclipse 120
dbg> elocals
dbg> estep over
dbg> estack
```

The same six commands are documented as working in vsp adt debug over HTTPS against a system with no gateway port. From an MCP client the loop is SetBreakpoint, then DebuggerListen, then DebuggerGetVariables, then DebuggerStep, then DebuggerDetach. The README notes that DebuggerListen attaches for you, because a debuggee is only attachable while it waits, so a caller that copies an id between two tool calls loses the race.

## Breakpoints, the ZADT_DEBUG facade, and where ADT will not answer

Breakpoints go through POST /sap/bc/adt/debugger/breakpoints, which the README says answers 200 on both transports and writes the same ABDBG_EXTDBPS row a Z facade would. There is one asymmetry the README admits rather than hides: SAP answers the GET with 200 and an empty body, because in ADT the breakpoint set is the IDE's state and Eclipse posts it whole rather than asking. A client therefore keeps its own record, and adding one breakpoint becomes a read-modify-write. That is a real limitation of the protocol, not of vsp, and the workaround shifts bookkeeping onto the caller. For systems where the ADT debugger resources are absent or blocked, the repository ships a typed, smaller-payload path over a small ABAP facade in abap/src/zadt_debug/. The README says that facade also covers the one thing ADT will not answer, reading the server's own breakpoint table. In that mode you name the include when setting an external breakpoint:

```bash
dbg> bp SAPLZADT_DEBUG/LZADT_DEBUGU01 9
dbg> catch 150
dbg> step over
dbg> stack
dbg> detach
```

Variables are read and written: elocals walks the debugger's variable tree to the stopped frame's data, and eset LV_AMOUNT 900 puts a value back so the next statement computes with it. Note the cost of the facade path. It requires shipping ABAP into the system, which is exactly the thing the RFC and HTTPS paths avoid, so it is a fallback rather than an equivalent.

## Cluster tables, spool, jobs and the application log: reading what only IMPORT could read

The last three releases added a second class of capability that has nothing to do with the debugger. vsp decodes cluster tables such as BALDAT, INDX and STXL, which are what an EXPORT ... TO DATABASE writes, over plain ADT. The README states that SAP's LZH and LZC compression is decompressed in Go, the cluster format is walked, and fields are named from DD03L, so data that previously required an ABAP IMPORT can be read without a line of ABAP. Around that, the application log is available by object and date range, and the README says the same log can be reconstructed from a bare SE16H export of two tables. Jobs and spool are handled as tables: SP01's list decoded from TemSe, a job's steps and its log, exported for a whole night in one command. A further group covers where settings live: a report's variants with the screen's own labels, SE37's saved test data, SE61 documentation as Markdown, and the IMG searched by title with the activity's transaction. Two smaller items matter for day-to-day editing: selection texts and text symbols written as a plan with a diff and activated so they stay, and a hint after every program create naming the fields still without one. The description can be set without touching the source. This is the part of the project that is hardest to replace with a generic HTTP client, because the decoding lives in Go rather than in a server-side exit.

## The response cache, and why a 4-second slim becomes 10 ms

The README describes a response cache that turns a 4-second slim into 10 ms, on Go-native SQLite when the cache should outlive the process. That number is the project's own claim, not an independent measurement. The design choice worth noting is the storage backend: modernc.org/sqlite appears in go.mod, which means the cache has no CGO dependency and the binary stays a single file. For a tool that is meant to be dropped next to an agent, that matters more than raw cache speed. The trade-off is that a cache in front of ADT responses is a cache in front of a live system. The README does not document cache invalidation rules, so if you edit ABAP outside vsp and then read through vsp, you should confirm for yourself what the cache does before assuming you are looking at current source.

## Where vsp is the wrong tool

The README is clear that the surface is release-dependent, and that is the first boundary. RAP work needs S/4, AMDP needs HANA, and some ADT resources present on S/4 are absent on ERP, so a 7.50 system may give you the debugger and little else. Run vsp compat before promising anyone a workflow. The second boundary is the breakpoint GET asymmetry: any client that assumes it can read the current breakpoint set from the server is wrong, and a read-modify-write loop against a shared system can clobber another developer's breakpoints. The third is the facade path. If ADT's debugger resources are blocked and you cannot deploy abap/src/zadt_debug/, you have no debugger at all. The fourth is operational. vsp is a client that writes ABAP and activates it, and the .env.example exposes SAP_READ_ONLY, SAP_BLOCK_FREE_SQL, SAP_ALLOWED_PACKAGES and SAP_ALLOWED_OPS precisely because unrestricted write access to a productive system is a bad idea. If your team has no transport discipline, this tool will not supply it. Finally, the README does not document rollback for a bad activation, so treat activation as a change you are prepared to reverse by hand.

## vsp compared with the OData bridge and with hand-rolled ADT clients

The README points to a sibling project, oisee/odata_mcp_go, described as an OData to MCP bridge for SAP data access. The split is clean: OData exposes business data through published services, while vsp goes at ADT, which is the development and debugging surface. If your problem is reading a purchase order, the OData bridge is the right shape. If your problem is reading the source of the function module that produced it, or stepping through it, vsp is the one that fits. The other alternative is writing your own ADT client. That is viable for source read and write, because those are ordinary HTTP calls, but the debugger is where it stops being viable: you would have to hold a session across calls, handle the roll area, and reproduce the conformance behaviour between an RFC tunnel and a stateful HTTPS session. The cluster-table decoding is the same story. LZH and LZC decompression plus the cluster format plus DD03L field naming is a body of work you would otherwise reimplement. Where a hand-rolled client wins is scope: if you need three ADT endpoints and nothing else, a small script has no tool surface to configure and no SAP_MODE to choose between 81 and 122 tools.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent and versioned semantically: v2.56.0 on 2026-09-05, v2.55.0 on 2026-09-04, v2.54.0 on 2026-08-27. That cadence cuts both ways. You get fixes quickly, and you also get a moving surface, which is why vsp update exists as a self-updating path verified against checksums.txt. The licence is MIT, and the repository carries a NOTICE file alongside LICENSE, which usually indicates bundled third-party material; read both if you redistribute the binary. MIT is permissive and imposes no copyleft on your own code, but it also means no warranty, and this is a tool that writes and activates objects in a live SAP system. That is a statement about the licence text, not legal advice. On upgrade cost, the practical risk is the tool surface, not the binary: SAP_MODE selects between 81 and 122 tools, and feature flags such as SAP_FEATURE_RAP, SAP_FEATURE_AMDP and SAP_FEATURE_HANA accept auto, on or off. If your MCP config names individual tools, a release that changes the set is a config change on your side, so pin the version you run and read the changelog before moving.

## Conclusion

Adopt vsp if you already have ADT access to a system at 7.50 or above and you want an assistant or script to read, edit and debug ABAP over the same resources Eclipse uses. Do not adopt it if you need a supported SAP product, if your system blocks the ADT debugger resources and you cannot ship the ZADT_DEBUG facade, or if nobody on the team can hold a transport request. Before anything else, run vsp compat against the target system and confirm which of RAP, AMDP, transport and UI5 features it reports, because the README is explicit that the available surface varies by release and that some ADT resources present on S/4 are absent on ERP. Then run the offline reviewer tasks in docs/reviewer-guide.md before pointing it at production.

## FAQ

### What is vibing-steampunk (vsp)?

It is an ADT to MCP bridge written in Go that gives Claude and other AI assistants access to SAP ADT APIs, so they can read code, write code, debug, deploy and run tests. The same resources are reachable from a CLI with a dbg> prompt for scripted use.

### Does vsp install anything on the SAP server?

The README states that nothing is installed on the server for the RFC and HTTPS debugger paths, because eclipse drives the same ADT resources Eclipse uses. There is an optional typed path over a small ABAP facade in abap/src/zadt_debug/ for systems where the ADT debugger resources are absent or blocked.

### Which SAP releases does vsp support?

The README says any system with ADT enabled, 7.50 upwards, but adds that the available surface varies by release: RAP needs S/4, AMDP needs HANA, and some ADT resources present on S/4 are absent on ERP. It provides vsp compat to report the surface per system.

### How do I get vsp?

The README documents vsp update as the release for your platform, verified against checksums.txt and renamed into place of the running binary. Building from source uses the repository Makefile, which produces a binary named vsp with the platform in the filename and a build/vsp link to it.

## Sources

- [Issues](https://github.com/oisee/vibing-steampunk/issues)
- [License: MIT](https://github.com/oisee/vibing-steampunk/blob/main/LICENSE)
- [oisee/vibing-steampunk on GitHub](https://github.com/oisee/vibing-steampunk)
- [README](https://github.com/oisee/vibing-steampunk/blob/main/README.md)
- [Releases](https://github.com/oisee/vibing-steampunk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oisee-vibing-steampunk