The MCP Delphi Build Server enables building and cleaning of Delphi, Free Pascal, and Lazarus projects.
Build Delphi projects: Compile .dproj or .groupproj files using MSBuild, with optional RAD Studio environment initialization via rsvars.bat.
Clean Delphi projects: Remove build artifacts from Delphi projects using MSBuild.
Build Free Pascal projects: Compile Pascal programs (.lpr/.pas) using the Free Pascal Compiler (FPC), with support for custom output paths, defines, unit/include search paths, and target OS/CPU selection.
Build Lazarus projects: Compile Lazarus .lpi projects using lazbuild, with options for target OS/CPU and build mode.
Clean Lazarus projects: Remove build artifacts from Lazarus projects using lazbuild --clean.
Configuration: Supports environment variables and input parameters for customizing paths to tools like rsvars.bat, msbuild.exe, fpc, and lazbuild, plus build settings like platform and configuration.
Provides tools for building and cleaning Delphi projects (.dproj/.groupproj files) using MSBuild with proper RAD Studio environment initialization
Integrates with Embarcadero RAD Studio toolchain to build and clean Delphi projects by initializing the development environment through rsvars.bat
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Delphi Build Server build my Delphi project MyApp.dproj for Win64 Release"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that exposes tools to build and clean Delphi projects (.dproj/.groupproj) on Windows using MSBuild, initializing the RAD Studio environment via rsvars.bat.
Windows
Node.js >= 18
Embarcadero RAD Studio installed (for rsvars.bat and Delphi toolchain)
MSBuild available (Visual Studio Build Tools or from RAD Studio toolchain)
Related MCP server: Delphi Build MCP Server
pnpm install
pnpm run buildOr with npm:
npm install
npm run buildYou can configure defaults via environment variables (use an .env file in this directory if you want):
RSVARS_BAT: Full path to rsvars.bat (e.g., C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\rsvars.bat)
MSBUILD_PATH: Full path to msbuild.exe if not in PATH
DELPHI_CONFIG: Default config (Debug/Release). Default: Release
DELPHI_PLATFORM: Default platform (Win32/Win64). Default: Win32
Create a .env file like:
RSVARS_BAT=C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\rsvars.bat
MSBUILD_PATH=C:\Program Files\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\MSBuild.exe
DELPHI_CONFIG=Release
DELPHI_PLATFORM=Win32This server speaks MCP over stdio. Start it with:
node --env-file=.env dist/server.jsOr, after installing globally (or as a dependency), run the bin:
mcp-delphi-serverDuring development:
pnpm run devdelphi.build
params: project (string, path to .dproj/.groupproj), configuration? (string), platform? (string), msbuildPath? (string), rsvarsPath? (string)
Builds the project using MSBuild. If rsvarsPath (or RSVARS_BAT env) is provided, it will be called before MSBuild in a single shell.
delphi.clean
params: same as delphi.build
Cleans the project.
fpc.build
params: source (string, path to .lpr/.pas), output? (string), defines? (string[]), unitPaths? (string[]), includePaths? (string[]), cpu? (string), os? (string), fpcPath? (string)
Compiles a Pascal program using Free Pascal Compiler. You can pass an explicit fpcPath or rely on PATH.
lazarus.build
params: project (string, path to .lpi), buildMode? (string), cpu? (string), os? (string), lazbuildPath? (string)
Builds a Lazarus project using lazbuild. Optionally set CPU/OS or build mode.
lazarus.clean
params: project (string, path to .lpi), lazbuildPath? (string)
Cleans Lazarus build artifacts via lazbuild --clean.
This repo includes small Delphi test projects in test/projects, and a Lazarus sample in test/projects/lazarus. Helper scripts live in scripts/.
Build all Release targets:
pnpm run test:build:all
Build individually (examples):
pnpm run test:build:console:win32
pnpm run test:build:console:win64
pnpm run test:build:vcl:win32
pnpm run test:build:vcl:win64
pnpm run test:build:group:win32
pnpm run test:build:group:win64
Clean variants also exist under test:clean:*.
Delphi via MSBuild
{
"name": "delphi.build",
"arguments": {
"project": "C:/path/to/MyApp.dproj",
"configuration": "Release",
"platform": "Win64"
}
}FPC on Windows (using explicit compiler path)
{
"name": "fpc.build",
"arguments": {
"source": "C:/path/to/lazarus/project1.lpr",
"cpu": "x86_64",
"os": "win64",
"fpcPath": "C:/path/to/fpc.exe"
}
}Lazarus via lazbuild on Windows
{
"name": "lazarus.build",
"arguments": {
"project": "C:/path/to/lazarus/project1.lpi",
"cpu": "x86_64",
"os": "win64",
"lazbuildPath": "C:/path/to/lazbuild.exe"
}
}Windows-first. Delphi integration requires RAD Studio toolchain and MSBuild.
For RAD Studio, rsvars.bat sets required environment variables (like BDS, FrameworkDir, Library path). It is recommended to set RSVARS_BAT to ensure the Delphi toolchain is available to MSBuild.
Group projects (.groupproj) are supported; MSBuild will traverse contained projects.
FPC/Lazarus support is included via fpc and lazbuild. Provide explicit paths on Windows if they are not in PATH.
Ensure dist is built: pnpm run build
Optionally test locally via: pnpm run test:build:all
Publish to npm:
npm publish (or pnpm publish)
If publishing under a scope, set the package name accordingly and ensure you are logged in with proper access.
Build a Delphi .dproj or .groupproj using MSBuild with RAD Studio environment
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Path to a Delphi .dproj or .groupproj file | |
| configuration | No | Release | |
| platform | No | Win64 | |
| msbuildPath | No | Optional path to msbuild.exe to use | |
| rsvarsPath | No | Optional path to rsvars.bat to initialize RAD Studio env |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the build action but doesn't disclose behavioral traits like whether this is a long-running operation, what happens on failure, if it modifies source files, or what output is produced. For a build tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place: 'Build' (action), 'Delphi .dproj or .groupproj' (target), 'using MSBuild with RAD Studio environment' (method). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a build tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens during execution, error conditions, or dependencies. The description provides basic purpose but lacks the contextual information needed for effective tool invocation in a complex build scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (3 of 5 parameters have descriptions). The description adds no additional parameter semantics beyond what's in the schema. It mentions MSBuild and RAD Studio environment which relate to 'msbuildPath' and 'rsvarsPath' parameters, but doesn't explain their purpose or relationships. With moderate schema coverage, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Build'), target resources ('.dproj or .groupproj'), and method ('using MSBuild with RAD Studio environment'). It distinguishes from sibling tools like 'delphi.clean' by focusing on building rather than cleaning, and from 'fpc.build' and 'lazarus.build' by specifying Delphi/RAD Studio instead of Free Pascal/Lazarus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (building Delphi projects with MSBuild/RAD Studio) but doesn't explicitly state when to use this tool versus alternatives. It doesn't mention when to prefer 'delphi.clean' first or when to use 'fpc.build' for Free Pascal projects instead. The context is clear but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean a Delphi .dproj or .groupproj using MSBuild with RAD Studio environment
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Path to a Delphi .dproj or .groupproj file | |
| configuration | No | ||
| platform | No | Win64 | |
| msbuildPath | No | ||
| rsvarsPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the method (MSBuild with RAD Studio environment) but doesn't describe effects (e.g., what files are deleted, whether it's destructive, permissions needed, or error handling). For a tool with potential file system impacts, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word earns its place by specifying the tool's purpose without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, low schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, parameter meanings, and expected outcomes, making it inadequate for safe and effective use by an AI agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), with only the 'project' parameter documented. The description adds no parameter details beyond implying the project type, failing to compensate for the coverage gap. It doesn't explain 'configuration', 'platform', 'msbuildPath', or 'rsvarsPath', leaving most parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clean') and the target resource ('Delphi .dproj or .groupproj'), specifying the method ('using MSBuild with RAD Studio environment'). It distinguishes from siblings like 'delphi.build' by focusing on cleaning rather than building, though it doesn't explicitly contrast with 'lazarus.clean' for non-Delphi projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. It implies usage for Delphi projects but doesn't specify scenarios (e.g., before rebuilding, to remove temporary files) or differentiate from 'lazarus.clean' for Lazarus projects. The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build with Free Pascal Compiler (fpc) for a Pascal program or project file
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Path to a Pascal program (.lpr/.pas) or unit to compile with FPC | |
| output | No | Optional output binary path/name | |
| defines | No | Conditional defines, e.g. FOO=1 | |
| unitPaths | No | Additional unit search paths (-Fu) | |
| includePaths | No | Additional include search paths (-Fi) | |
| cpu | No | Target CPU, e.g. x86_64, i386, aarch64 | |
| os | No | Target OS, e.g. win64, win32, linux | |
| fpcPath | No | Path to fpc compiler (defaults to "fpc") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Build') but lacks behavioral details such as whether this is a read-only or destructive operation, error handling, output format, or runtime implications. For a compilation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action ('Build with Free Pascal Compiler') and specifying the target. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is inadequate. It lacks behavioral context, usage guidelines, and details on return values or errors, leaving significant gaps for an AI agent to understand how to invoke it correctly beyond basic parameter input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds no parameter-specific semantics beyond implying compilation of Pascal files, which is already covered by the schema. Baseline 3 is appropriate as the schema does the heavy lifting, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Build') and resource ('with Free Pascal Compiler for a Pascal program or project file'), making the purpose evident. It distinguishes from siblings like 'delphi.build' and 'lazarus.build' by specifying FPC, but doesn't explicitly contrast with them or mention non-compilation alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'delphi.build' or 'lazarus.build' is provided. The description implies usage for FPC compilation but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Lazarus (.lpi) project using lazbuild
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Path to a Lazarus project file (.lpi) | |
| buildMode | No | Lazarus build mode name (maps to --bm) | |
| cpu | No | Target CPU for lazbuild (e.g. x86_64, i386, aarch64) | |
| os | No | Target OS for lazbuild (e.g. win64, win32, linux) | |
| lazbuildPath | No | Path to lazbuild (defaults to "lazbuild") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'builds' a project, implying a potentially resource-intensive operation, but doesn't mention execution time, side effects, error handling, or output format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a build tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'build' entails operationally, what happens on success/failure, or how to interpret results, leaving significant gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage. The baseline score of 3 is appropriate since the schema fully documents all parameters, though the description doesn't enhance understanding of their semantics or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build') and the resource ('a Lazarus (.lpi) project using lazbuild'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'fpc.build' or 'delphi.build' beyond mentioning Lazarus specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'fpc.build' or 'lazarus.clean'. It doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean Lazarus build artifacts using lazbuild --clean
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Path to a Lazarus project file (.lpi) | |
| lazbuildPath | No | Path to lazbuild (defaults to "lazbuild") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the command 'lazbuild --clean' but doesn't disclose behavioral traits such as whether it's destructive (likely yes, as it cleans artifacts), permission requirements, or error handling. This leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the purpose clearly and uses minimal words to convey the essential action and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, and return values, which are critical for understanding how to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond implying the 'project' parameter is used with 'lazbuild --clean', which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clean') and target ('Lazarus build artifacts') using a specific command ('lazbuild --clean'). It distinguishes from siblings like 'lazarus.build' by focusing on cleanup rather than building, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'delphi.clean' or 'fpc.build'. The description implies usage for cleaning Lazarus projects but lacks context about prerequisites, timing, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0delphi.build1 field changedInput schema / properties / platform / defaultPrevious value: -"Win32"New value: +"Win64"delphi.clean1 field changedInput schema / properties / platform / defaultPrevious value: -"Win32"New value: +"Win64"delphi.builddelphi.cleanfpc.buildlazarus.buildlazarus.cleanEach tool has a clearly distinct purpose based on the compiler/environment (Delphi vs. FPC vs. Lazarus) and action (build vs. clean). There is no ambiguity between tools, as they target specific combinations of platform and operation.
All tools follow a consistent prefix.verb_noun pattern (e.g., delphi.build, lazarus.clean), with clear prefixes indicating the environment and verbs indicating the action. This predictable naming makes it easy to understand and navigate the tool set.
With 5 tools, the server is well-scoped for building and cleaning projects across three Pascal-based environments (Delphi, FPC, Lazarus). Each tool earns its place by covering essential operations without redundancy or unnecessary complexity.
The tool set covers build and clean operations for the main Pascal environments, but there are minor gaps such as missing run, test, or configuration tools. However, agents can work around these gaps, and the core workflows for building are adequately covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Generate wiki docs from source code. Supports PowerShell, Python, Go, C#, Java, COBOL.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flydev-fr/mcp-delphi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server