abap2UI5

Appearance

Agent Setup ​

Start here

AI Setup: The Recommended Path is the short version: three steps, one command each. This page explains what each step does and why.

Developing with AI is the one paragraph to paste and the index to point an assistant at. This page is the rest: everything that turns an assistant that knows abap2UI5 into one that can check its own work. The sections follow the steps of the recommended path; each one is useful on its own.

Put the conventions in the repository ​

An index tells an agent what abap2UI5 is. AGENTS.md tells it what your project is — and it is read automatically, by every session, without anybody remembering to paste anything.

The app-template ships one written for app-building: the class shape, the lifecycle, the view builder, binding, events, and the checks to run before calling the work done. It also ships a .claude/settings.json allowlist so an agent can run npm run check itself instead of stopping to ask.

Give it the checks ​

An agent that cannot check its own work will hand you an app that does not render. The two checks of the template need no SAP system, which means an agent can run them on its own:

sh
npm run check

The abap2UI5 linter half is the one that matters here. It reconstructs the view from the builder chain. Then it reports the names UI5 does not have, the properties that do not exist on the release you target, and the bindings that point at nothing.

Give it the MCP server ​

The MCP server lets the agent write, check, run and look at an app, again and again, still without a system. It works with any MCP client — Claude Code, Cursor, VS Code:

sh
claude mcp add abap2ui5 -- npx --yes -p @abap2ui5/mcp-server abap2ui5-mcp

The tools an agent then has:

examplessearch the three sample catalogs — has somebody already built a value help, a tree, navigation between two apps? Answers with a class to read, never with a snippet to trust
capabilitieswhether abap2UI5 can express a UI5 feature at all, from the verified capability map
validate_viewthe linter's checks, in seconds, against your project's own config
deploy_appwrite the class into a local sandbox and compile it
build_backend / run_appget the framework already transpiled to Node, transpile the app on top, boot it headless, and hand back the errors and a screenshot
pitfallsthe defects a green run still does not catch — abapGit import, activation, the oldest UI5 release

The setup has levels: checking views needs one small checkout and a minute; screenshots of the running app need a browser and a first build of a minute at most. Stop at the level you need. The MCP Server page has the levels, every tool and the order they are meant to be used in.

From the editor ​

The VS Code extension registers that same MCP server for every client in the window: Copilot agent mode, Claude Code, anything else speaking MCP. So an agent working in your editor has these tools without any separate configuration. Point abap2ui5.mcp.reposRoot at the folder holding the checkouts and the extension passes the paths through.

It adds a second server of its own for the half that one deliberately does not have: your configured systems. An agent can list them, search app classes over ADT and get the app rendered on the real system as a screenshot. Every credential prompt stays an ordinary VS Code dialog that the agent never sees.

Let it operate the app ​

An agent can also use the app it wrote, not only look at it. Four tools read the screen as data, fill fields by model path and fire events by name, over the app's own JSON protocol. They exist in three places:

  • in the MCP server, against the local sandbox
  • in the VS Code extension, against your system once you allow it
  • as an MCP endpoint inside the SAP system, for agents working on behalf of users

Agent-Operable Apps covers all three.

Next Steps ​