Delphi IDE Remote MCP Server

An MCP server that remote-controls a full RAD Studio (Delphi IDE) installation — language server, build system, deploy chain — so you can develop in Delphi from any platform. And the agent gets eyes and hands on a real screen too — an Android device, a Linux GNOME desktop or a Windows desktop behind a PAServer (the server's own included): it sees what is there and drives it.

📦 Download the ready-made Windows binary → (no Delphi needed to run the server binary; the machine it runs on needs its own licensed RAD Studio). 🚀 Quickstart: five steps from zero to the first call → — unzip on the Delphi PC, a five-line settings.ini, -gui, connect a client, delphi_workspace.

The Windows machine holds RAD Studio and the projects. You work from wherever you actually want to be: a Linux laptop, a Mac, a cloud agent, a CI runner. Understand the code, edit it safely, scaffold, build, run, package, fetch the binaries, commit — and then deploy to a real target and watch your app run there, pressing its buttons yourself — the whole cycle over MCP, with Delphi installed on neither the client nor the agent.

It is not a language-server bridge. Semantic understanding is one capability of many, and it is the one that is genuinely hard, so it runs on Embarcadero's official DelphiLSP.exe — the same engine behind Code Insight in the RAD Studio IDE. But the language server backs 8 of the 41 tools; the other 33 are the working day: the safe editing engine, MSBuild, git, the file tools, the project scaffolder, the deploy chain (PAServer, adb), the knowledge vault. See What each tool actually runs on for the exact split.

Runs as a Windows Service, a terminal process or a tray app — one executable, three modes — keeping language-server processes warm across agent sessions and serving multiple AI clients (Claude Code, Claude Desktop, or any MCP client) over Streamable HTTP, with a classic stdio mode as well.

Status: stable (1.9.0). Covered by 93 end-to-end batteries — 2,983 checks — against DelphiLSP 37.0 (RAD Studio 13), and by a full day of real-world field testing by an independent agent using it as a client. A minor version adds tools or capabilities, a patch fixes, and a documented contract that changes is announced in the CHANGELOG first. See docs/ARCHITECTURE.md and docs/DELPHILSP-NOTES.md for the measured research this project is built on, CHANGELOG.md for versions, and docs/ROADMAP.md for what is delivered, open, parked or declined.

Why

AI agents working on Delphi codebases are usually limited to text search (grep). This server gives them the full remote development workflow over Delphi and its projects — understand, edit safely, verify, build, deploy, run and drive the result — through the real compiler front-end and inside an operator-declared jail. In short: RAD Studio turned into a remote backend for programming agents.

The core idea: centralize Delphi, work from anywhere. One Windows PC or VM holds the RAD Studio installation and the projects; this server runs there. Everything else — your laptop, a Linux box, a CI runner, an agent in the cloud — connects over MCP HTTP and gets the full development cycle (locate a project, read, edit, scaffold, build, run, download the binaries, commit) without installing Delphi, or anything at all, on the client side.

The showpiece: your app on a real Linux desktop, seen and driven from the agent. Deploy to a GNOME machine through PAServer, launch it with remote-run (the program is not killed when the call returns — a window is meant to stay up), and then delphi_desktop brings the whole desktop back as a PNG, presses the exact pixel you measured, types into your app, walks its windows. Beyond PAServer itself there are no prerequisites and nothing to install by hand on the target: it executes what this server sends, and the tiny helper node — shipped inside this release — deploys and updates itself on first use. It is the same eyes-and-hands idea delphi_adb gives you on Android — pointed at a Linux desktop. Today it speaks GNOME (Zorin and Fedora, measured live). And the node itself is the proof of the whole premise: it was developed entirely through this server — an AI agent on the other end of the MCP wrote it, compiled it, deployed it and debugged it against the live targets, without ever sitting at the Windows machine. This repo dogfoods its own tools.

And the same eyes and hands on a Windows desktop - including the server's own. Since 1.0.16 there is ONE desktop tool, delphi_desktop, and the machine is a parameter: the PAServer profile. Point it at a Linux, at a Windows with PAServer, or at this very server when a PAServer runs in its user session (windows-local, 127.0.0.1): same node, same gestures, same permissions (AllowRemoteRun, RemoteHosts, RemoteRunProjects). Every remote execution - Linux or Windows - goes through ONE mechanism: a job file (the binary, the output file, then one argument per line) and a native launcher (node\McpRunJob, node\McpRunJob.exe) that PAServer starts; there is no shell in the path, so an agent's arguments reach the program as argv, untouched. The old name, delphi_adb_linux, no longer exists.

Use cases

Two credential levels — a full read-write token, and a read-only one — let very different agents share the same live codebase safely. The read-only level can read, search, navigate symbols, get diagnostics, follow definitions into RTL/VCL and installed components, download files and run query-only git; it can touch nothing on the server. That opens up a range of setups:

• Move your daily work to another OS. The Windows box with RAD Studio becomes a remote build server; you drive it from a Linux laptop, a Mac, or a cloud agent. Full read-write token, VPN/LAN only. Edit, scaffold, build, run, fetch the binaries, commit — Delphi never leaves the server.
• Deploy-and-verify on a real Linux desktop, hands on the app. Build on Windows, deploy over PAServer, launch with remote-run, then SEE the GNOME desktop and drive the app — tap its buttons, type into its fields, close its windows — all from the agent, with nothing installed on the Linux box. The closing mile of the cycle: not "it compiled", but "I watched it run and used it". Since 1.0.16 the launch also works when PAServer runs as a service on the target: the launcher completes the graphical session's DISPLAY / WAYLAND_DISPLAY / XAUTHORITY when PAServer did not inherit them, and the answer says so (graphicalEnv).
• A documentation / wiki / RAG agent that cross-checks the real source. Give it the read-only token. It maintains the wiki or answers questions from a RAG index, and whenever it needs to be sure, it confirms the claim against the actual code — "does TOrderService.Post really validate the tax id?" — instead of trusting a possibly-stale document. Grounded answers, zero write risk.
• A code-review / audit agent on every branch. Read-only. It reads diffs, walks symbols with compiler-grade accuracy, follows calls cross-unit and into VCL, runs on-demand diagnostics (real E/W/H codes, no build) — and cannot alter the tree it is reviewing.
• An onboarding / Q&A assistant for the team. Read-only, pointed at the whole Roots. New developers ask "where is X handled, what calls Y, what's the type of Z" and get answers from the live sources, not a wiki that drifts.
• The programming agent + the reviewing agent, side by side. One holds the read-write token and does the work; another holds the read-only token and independently checks it — two agents, one codebase, only one able to write.
• A CI / release runner. Read-write on a locked-down VM: pull, build Release, package the deploy, upload/fetch artifacts, tag — all over MCP, no interactive IDE.

An agent can also be pointed at the library read zone (RTL/VCL sources and installed third-party components) to reason about framework or component internals, still without any write capability.

Several agents at once is a supported case, and it is measured. The HTTP host serves every request on its own thread, and each one carries its own workspace and access level, so two agents with different tokens never see each other's jail. Where they DO meet is the machine underneath: the writes of one file, a project's .dpr, msbuild, the desktop, a target machine. Those are serialized — one build at a time (the answer says how long it queued), one edit at a time per server, one gesture at a time per desktop or per PAServer profile — and the artifacts that used to collide (screenshots, reports, packages, backups) now carry a name of their own. tests/test_concurrencia.py fires bursts of simultaneous agents at all of it and checks the disk afterwards. Two caveats stay honest: the locks are per process, so running a second server against the same tree (a tray plus a stdio client, for instance) puts them outside each other's reach; and serialized is not coordinated — two agents editing the same file take turns, they do not agree.

What each tool actually runs on

The language server is the hardest part to get right, but it is not most of the server. Of the 36 core tools, exactly 8 are backed by DelphiLSP; the other 28 never touch it (plus 5 optional vault_* tools, registered only when you configure a vault). This matters in practice: the LSP-backed tools are the only ones that need a resolvable project configuration — the rest work on any folder inside the roots.

Backed by DelphiLSP (8): delphi_symbols, delphi_definition, delphi_hover, delphi_completion, delphi_signature, delphi_diagnostics, delphi_references (hybrid — LSP-validated, see the table) and delphi_rename_symbol (semantic rename built on definition + references; mode=apply writes it through the changeset engine).

NOT DelphiLSP (the other 28): delphi_read, delphi_edit, delphi_textedit, delphi_create, delphi_build, delphi_list, delphi_search, delphi_projects, delphi_workspace, delphi_move, delphi_delete, delphi_fetch, delphi_upload, delphi_package, delphi_git, delphi_installs, delphi_config, delphi_paserver, delphi_adb, delphi_desktop, delphi_components, delphi_styles, delphi_messages, delphi_changeset, delphi_designer, delphi_test, delphi_report, delphi_help — plus the 5 vault_* tools. These run on MSBuild, git, the filesystem, the registry, adb, the safe-editing engine and your vault.

The table below says which engine each one uses and why it matters:

| Engine | Tools | What that means for you | |---|---|---| | DelphiLSP (official, compiler-grade) | delphi_symbols, delphi_definition, delphi_hover, delphi_completion, delphi_signature, delphi_diagnostics | Real semantic answers, not grep: resolves inheritance, with, overloads, and follows into RTL/VCL. Needs a .delphilsp.json (used when fresh, fabricated from the .dproj when not). | | DelphiLSP + disk scan (hybrid) | delphi_references | The LSP has no references, so candidates are scanned from disk and then each one is validated by asking the LSP where it resolves to. Verified aga