abap2UI5

mcp-server

The MCP server for abap2UI5 — gives any AI coding agent (Claude Code, Cursor, VS Code Copilot, or any MCP client) the full abap2UI5 development loop, without an SAP system:

examples -> app_guide -> validate_view + screenshot_view -> deploy_app -> build_backend -> run_app -> pitfalls

(has somebody (how an app (SECONDS, no system: (write ABAP, (transpile (boot headless, (what a green built it is built) is the view legal, lint) to Node) errors + run still already?) and what does it LOOK like) SCREENSHOT) does not prove)

The agent writes an ABAP class, validates the view and looks at a picture of it in seconds, deploys it, boots it in a real browser and looks at the running app — then iterates. Everything runs locally on infrastructure that already guards the abap2UI5 ecosystem in CI: the abaplint transpiler + open-abap runtime, the framework's express shim, the samples-controls build and boot gates, and the linter validation core.

Documentation

→ [The MCP server, in full](https://abap2ui5.github.io/docs/advanced/mcp_server.html) — what MCP means here, the three setup levels and what each one buys, how to register the server with your client, every tool with what the agent gets from it, and the loop they are meant to be used in.

→ [Building with AI](https://abap2ui5.github.io/docs/get_started/ai.html) — the whole AI setup in rising order of effort. This server is the top rung; the cheaper ones matter first.

Quick start

One-click install

Every button registers the same stdio server, named abap2ui5:

{"command":"npx","args":["--yes","-p","@abap2ui5/mcp-server","abap2ui5-mcp"]}

The badges go through a web redirect because GitHub does not render links to an editor's own URL scheme; the direct links, to paste into a browser or xdg-open/open, are:

vscode:mcp/install?%7B%22name%22%3A%22abap2ui5%22%2C%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22--yes%22%2C%22-p%22%2C%22%40abap2ui5%2Fmcp-server%22%2C%22abap2ui5-mcp%22%5D%7D

cursor://anysphere.cursor-deeplink/mcp/install?name=abap2ui5&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyItLXllcyIsIi1wIiwiQGFiYXAydWk1L21jcC1zZXJ2ZXIiLCJhYmFwMnVpNS1tY3AiXX0%3D

(vscode-insiders: in place of vscode: for Insiders.) Claude Code:

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

Claude Code plugin. The abap2UI5 plugin bundles the framework's agent skills (building an app, the ABAP and UI5 pitfall catalogues, the view-chain layout, ...) together with this server, registered the same way as above — one install for both:

/plugin marketplace add abap2UI5/abap2UI5

/plugin install abap2ui5@abap2ui5

Releases from 1.0.0 on are also listed in the official MCP Registry as io.github.abap2UI5/mcp-server (server.json), for clients that install from the registry. The same command is what the Smithery (smithery.yaml) and Glama (glama.json) directories list: one npm package, one version, whichever catalogue a client reads.

That is level 1 below: validate_view and fix_view work out of the box, and setup_status tells the agent what else works on this machine and what is missing.

What each install brings

Level 1 — validate_view, fix_view and screenshot_view, the tools most work happens at. They need the linter, which the server declares as a peer dependency (@abap2ui5/linter, >=0.8.0 <0.10.0 — the range this server is built against). npm 7+ installs a non-optional peer by itself, so the one-liner below brings the linter along and validate_view/fix_view work out of the box. The render gate behind screenshot_view needs the UI5 libraries and Playwright on top (@abap2ui5/linter-render, declared as an optional peer: the compatible range is stated, the package is NOT installed for you — plan on ~150–200 MB and a few minutes the first time you add it):

claude mcp add abap2ui5 -- npx --yes -p @abap2ui5/mcp-server abap2ui5-mcp                            # validate_view, fix_view

claude mcp add abap2ui5 -- npx --yes -p @abap2ui5/mcp-server -p @abap2ui5/linter-render abap2ui5-mcp # + screenshot_view

The server looks for the linter, in this order: AI_VIEW_CHECK_HOME; a linter checkout next to the server (which is also where npm puts the peer for an npx run: node_modules/@abap2ui5/{mcp-server,linter}); the project it is started in (node_modules/@abap2ui5/linter — app-template has it as a devDependency, so npm install there is all it takes); the server's own node_modules; whatever Node's module resolution finds from the server's location. A set env var decides alone. Or work from a checkout:

git clone https://github.com/abap2UI5/linter        # AI_VIEW_CHECK_HOME

cd linter && npm ci

The server itself is on npm, so it needs no checkout; the registration above is the whole install. (With npm 6 or --legacy-peer-deps, add -p @abap2ui5/linter yourself.)

(-p … abap2ui5-mcp names the bin explicitly, which every published version answers. The shorter npx --yes @abap2ui5/mcp-server needs a bin named after the package, which 0.2.0 and earlier do not have — npx stops there with "could not determine executable to run".)

(The install is ~47 MB: 19 MB of it a Playwright driver only run_app uses, 2 MB the linter — paid on the first start, cached after. From a checkout instead: git clone https://github.com/abap2UI5/mcp-server && cd mcp-server && npm ci, then claude mcp add abap2ui5 -- node /path/to/mcp-server/server.mjs.)

Cursor, VS Code and Claude Desktop take the standard stdio shape — the documentation has the JSON, and the two further levels (the sample catalogues and deploying, then the headless build-and-boot loop). A tool whose prerequisites are missing answers with a message naming what it needs; the server starts either way.

The abap2UI5 VS Code extension registers this server for you, and adds a second one of its own for the tools that need a real SAP system.

Everything in one command — for a machine (or Codespace) dedicated to the full build-and-boot loop, setup.sh clones the framework, corpus and linter checkouts next to this repo, installs their dependencies and the headless browser (existing checkouts are reused, safe to re-run):

git clone https://github.com/abap2UI5/mcp-server && ./mcp-server/setup.sh

setup.sh --no-corpus clones the framework and the linter only, which is the whole loop for an app of your own since the framework sandbox exists; the corpus is for scope_of, the full build and the locally served UI5.

A Claude Code started inside the checkout picks the server up automatically via the committed .mcp.json; the devcontainer runs the same setup on create.

Level 0 — no checkout at all. The knowledge tools (app_guide, api_reference, pitfalls, capabilities, examples, read_example, docs_search, scaffold_app, generation_rules) read committed files, so when no checkout resolves and no env var is set they read them from GitHub instead: the files land in a per-user cache ( /abap2ui5-mcp-remote, a day at a time - used only while it is a directory of the user's own, created 0700; A2UI5_MCP_REMOTE_DIR moves it) that the server treats as a read-only checkout; add_agent_setup reads the template from there too, and writes only into the project it is given. And the expensive half runs on the npm package @abap2ui5/node-runtime (below), so npx --yes -p @abap2ui5/mcp-server abap2ui5-mcp in a fresh project covers deploy_app, build_backend, run_app, interact_app, run_unit_tests and verify_app too, with no clone of anything. What still needs a checkout is the corpus' part (scope_of, build_backend mode full, the locally served UI5). A2UI5_MCP_REMOTE=0 or A2UI5_MCP_OFFLINE=1 switches the mirror off. The docs mirror lists its pages through GitHub's API, which allows 60 unauthenticated requests an hour per address; a GITHUB_TOKEN (or GH_TOKEN) in the environment raises that and is sent to api.github.com only.

The backend without a framework checkout: `@abap2ui5/node-runtime`. The framework is published on npm already transpiled, with the ABAP sources of the same release commit to transpile apps against. With no abap2UI5 checkout (and none configured), build_backend installs that package once per release into ~/.abap2ui5-mcp/runtime/ — with the transpiler it names, express, and app-template's abaplint for the lint, at exact versions with a lockfile, --ignore-scripts — fetches open-abap-core at the commit the release was built with, and then transpiles only the deployed apps against it: seconds, never the framework. deploy_app writes into ~/.abap2ui5-mcp/sandbox (and lints with app-template's own config against the package's sources), run_app boots the package's server with the apps registered, run_unit_tests runs the apps' own tests. The release is the registry's latest (asked through npm, cached a day) unless A2UI5_MCP_RUNTIME_VERSION pins one. Measured here with a cold npm cache: the first install about 10 s, open-abap-core about 1 s, then 7–8 s per build and about a second for the unit tests. setup_status shows the release, the workspace and what the next build would do.

With a framework checkout (A2UI5_HOME or a sibling) everything works as before: build_backend downloads the release's prebuilt backend (backend- .tar.gz) into the checkout the first time and re-transpiles the deployed apps from its node/zz_dev afterwards. A2UI5_MCP_BACKEND=npm runs on the package beside a checkout; build_backend mode prebuilt (or A2UI5_MCP_BACKEND=clone) clones the release into ~/.abap2ui5-mcp/abap2UI5 instead — the path this server took without a checkout until the package existed. The full corpus build stays available as mode: "full" for a checkout on an unreleased commit.

Tools

Every tool reads live from a sibling checkout, and each one needs a specific sibling — there is no "optional" repository, only tools you do or do not use. The Needs column says which checkout a tool is dead without: the linter alone carries validate_view, fix_view and screenshot_view (the fast loop, where most iterations happen — and the one dependency npm installs with the server, as its declared peer), the framework checkout carries the guide, the pitfalls and the inte