vs-punk: an ADT to MCP bridge for ABAP systems

The problem vsp addresses: ADT is a good API with no agent-friendly surface

SAP's ADT endpoints are what Eclipse uses to read source, set breakpoints, walk a call stack and inspect variables. They are documented only by their consumers, they assume a long-lived IDE session, and they are not shaped like a tool interface an AI assistant can call. vsp is a Go binary that sits between an MCP client and those endpoints and translates calls in both directions. The README frames the target audience as anyone doing ABAP or AMDP work who wants to drive it from natural language, or from a DSL when automation is the goal. The repository topics (abap, adt, mcp, vibe-coding) match that framing. The scope claim is broad: any system with ADT enabled, 7.50 upwards, with the caveat that the available surface varies by release and RAP needs S/4 while AMDP needs HANA. That caveat matters more than the headline, because a bridge is only as useful as the endpoints the remote system actually exposes.

Why the debugger needs a pinned session, not a series of HTTP calls

The README is unusually direct about the failure mode that shaped the architecture. The debugger needs a stable ABAP session. A debug loop spread over independent HTTP calls kept losing its debuggee, because ADT keeps the debug session in an ABAP roll area that is reachable again only through a sap-contextid cookie. Over a pinned classic-RFC conversation, the roll area is the session, so there is nothing to correlate. That is the whole reason vsp rfc debug exists as a distinct mode. The commands shown are ebp to set a breakpoint by object name, eclipse to listen and attach, elocals for the stopped frame's variables, estep over, estack. The same six commands are said to work in vsp adt debug over HTTPS against a system with no gateway port, where the stateful ICF session selected by sap-contextid plays the same role. An integration test is described as running the script over both transports and failing if they disagree about where the debuggee stopped or what it could see. That is a stronger correctness claim than most bridges make, and it is testable by anyone who can reach both transports.

The MCP surface and the attach race it is designed around

From an MCP client the debug loop is SetBreakpoint, then DebuggerListen, then DebuggerGetVariables, DebuggerStep, DebuggerDetach. The README gives a reason for folding listen and attach together: a debuggee is only attachable while it waits, so a caller that has to copy an id between two tool calls loses the race. That is a concrete design decision driven by a timing constraint in the underlying system, not a stylistic choice. Breakpoints are handled with an explicit acknowledgment of an asymmetry: POST /sap/bc/adt/debugger/breakpoints answers 200 on both transports and writes the same ABDBG_EXTDBPS row a Z facade would, but 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. The consequence is stated plainly: a client keeps its own record, and adding one breakpoint is a read-modify-write. Anyone building on top of vsp should expect that read-modify-write pattern and the consistency questions that come with it when two clients hold different views of the breakpoint set.

The fallback path when ADT debugger resources are missing

Not every system exposes the ADT debugger resources, and some block them. vsp carries a second, typed path over a small ABAP facade at abap/src/zadt_debug. This path is described as smaller-payload and useful for one thing ADT will not answer: reading the server's own breakpoint table. The command sequence differs. bp SAPLZADT_DEBUG/LZADT_DEBUGU01 9 sets an external breakpoint and the README notes you must name the include. catch 150 waits for a hit, attaches and shows the stack, then step over, stack, detach. The trade-off is explicit: this path requires installing the facade on the server, which contradicts the nothing installed claim that applies to the ADT path. Teams that cannot deploy ABAP objects to the target system lose this fallback entirely, and with it the ability to inspect the server breakpoint table. The README says both paths were proven live on A4H, with the breakpoint hit by a function module called over a second RFC connection and the stack showing %_RFC_START to REMOTE_FUNCTION_CALL to the module. It also states that variables are read and written, with eset LV_AMOUNT 900 putting a value back into the stopped frame.

Cluster tables, spool, jobs and the release cadence behind them

The recent release notes describe a run of features that go well beyond code editing. v2.55.0 is titled what only IMPORT could read, and covers cluster tables (BALDAT, INDX, STXL) read over plain ADT with SAP's LZH and LZC decompressed in Go, the cluster format walked and fields named from DD03L. v2.56.0 is titled the other half of a root cause and adds the application log by object and date range, plus spool and jobs (SP01 and SM37 as tables), with a job's steps and log exported for a whole night in one command. v2.54.0 is titled defaults chosen for a terminal, paid for in a context window, which is the kind of title that suggests a deliberate reversal of an earlier default. The README also lists a response cache described as turning a 4-second slim into 10 ms, on Go-native SQLite when it should outlive the process, and a vsp update command that verifies the release against checksums.txt and renames the binary into place of the running one. The cadence is fast, roughly weekly through August and September 2026, which is the main maintenance cost signal in the material.

Where the documentation is thin and where the tool is the wrong choice

The README is long on mechanism and short on operations. There is no section describing what happens when a pinned RFC conversation drops mid-debug, whether vsp reconnects, or what state a caller is left holding. The response cache is described by its effect and its storage engine, not by its invalidation rules, so a user cannot tell from the README whether a cached slim result can go stale after a change made outside vsp. The update command verifies checksums, which covers transport integrity, but nothing in the material describes rollback if the renamed binary misbehaves. The compat story is the sharpest limitation: the README states plainly that some ADT resources present on S/4 are absent on ERP, that RAP needs S/4 and AMDP needs HANA, and that vsp compat reports the surface per system. That means a workflow validated on one system can fail on another with no code change and no obvious error, and the only defense is running compat first. Teams on ERP releases who expect RAP tooling should treat vsp as the wrong tool rather than a partially working one.

The alternative: the OData bridge and what it does differently

The README points to a sibling project, oisee/odata_mcp_go, described as an OData to MCP bridge for SAP data access. The difference in approach is the layer each one targets. OData exposes business data through published services with a stable, documented contract; ADT exposes development artifacts and the debugger through the endpoints Eclipse uses. If your task is querying or writing business objects, the OData bridge matches the problem and avoids the session-pinning complexity that dominates vsp. If your task is reading source, stepping through a function module, or decoding a cluster table, OData has no equivalent surface and vsp is the only one of the two that applies. The projects are complementary rather than competing, and the README treats them that way. The real alternative for debugger work is Eclipse itself, which uses the same ADT resources and is the reference consumer. Choosing vsp over Eclipse means accepting an MCP-shaped interface and the session handling that comes with it, in exchange for scriptability and agent access.

Licence, upgrade cost and what to verify before adopting

vsp is MIT licensed, which permits commercial use and modification with the usual attribution requirement. The material does not discuss what happens to the ABAP facade under abap/src/zadt_debug when it is deployed into a customer system, and that is worth checking before installing it, because ABAP objects deployed to a productive system carry their own transport and change-control obligations that an MIT licence on the Go binary does not address. This is not legal advice; read the licence text and your own SAP agreements. On maintenance, the weekly release cadence implies that pinning to a version is safer than tracking main, and vsp update exists precisely so you can move deliberately. The first thing to run on any target system is vsp compat, because the README's own caveats about release-dependent surface mean that everything else in this article is conditional on what that command reports. After that, the reviewer guide at docs/reviewer-guide.md is described as 11 hands-on tasks with 6 fully offline, which is the cheapest way to find out whether the offline subset covers your workflow before you ask for an RFC user.

Editorial conclusion

Adopt vsp if your ABAP system has ADT enabled at 7.50 or above, you need debugger access without a server-side install, and your team already drives an MCP client. Do not adopt it if you cannot obtain an RFC user or a stateful HTTPS session, or if you need RAP on an ERP release. Before committing, run vsp compat against each target system and confirm the specific ADT resources your workflow depends on are present.

Official sources

1. Issues
2. License: MIT
3. oisee/vibing-steampunk on GitHub
4. README
5. Releases