Skip to main content
Glama
tina4stack

Claude Pascal MCP Server

by tina4stack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

build_dproj

Compile existing Delphi .dproj projects with MSBuild, honoring full build configurations, and optionally deploy artifacts for Android, iOS, macOS, or Linux.

Instructions

Build an existing Delphi .dproj project file using MSBuild + rsvars.bat.

Use this for real-world multi-file Delphi projects (CuttlefishV2.dproj, etc.) — anything that already exists on disk with its own .dproj, .dpr, units, forms, search paths, conditional defines, and resources. Honours the project's full build configuration exactly as RAD Studio would, no template substitution.

NOTE: compile_delphi_project is for generating a new throwaway project from a TButton/TEdit/TLabel/TMemo template. build_dproj is for building an existing real project. Use the right one.

STAGING CLEAN (Android / iOS / macOS / Linux): Delphi's own MSBuild Clean/Rebuild targets do NOT fully clean staging-based build pipelines. They wipe DCU/.o files but leave the PAClient (Android) or PAServer (iOS/macOS/Linux) staging directory and the previous artifact in place. That causes the classic "I changed code/assets but the new APK/app didn't update" symptom. When platform is Android/iOS/macOS/Linux and target is Rebuild or Clean, this tool automatically deep-cleans the platform's intermediate and bin directories before invoking MSBuild. Pass deep_clean=False to disable, or deep_clean=True to force it.

OUTPUT PATHS: this tool reads the .dproj's own DCC_ExeOutput / DCC_DcuOutput / DCC_BplOutput properties (resolved by MSBuild, honouring conditional PropertyGroups, $(Platform)/$(Config) substitution, base config inheritance, etc.) and uses those for both deep_clean and artifact resolution. So if your dproj points outputs at ..\bin$(Platform)$(Config) or anywhere else non-default, this tool follows. Safe guard: paths resolving outside the project tree (e.g. the shared C:\Users\Public...\Bpl\ system dir) are NEVER deep-cleaned; the trace will list them as "Skipped".

PASERVER (iOS / macOS / Linux): cross-builds for these platforms run through PAServer on a remote Mac or Linux host. Pass remote_profile with the name of a Connection Profile already configured in RAD Studio (Tools → Options → Environment Options → Connection Profile Manager). PAServer must be running on the target host. If the .dproj already pins a default profile you can omit remote_profile, but explicit is safer. This tool does not create profiles or store credentials — the profile must already exist locally on the dev machine.

Args: dproj_path: Absolute path to the .dproj file (e.g. r"D:\projects\cuttlefishmobile\src\CuttlefishV2.dproj"). config: Build config — Debug, Release, etc. (default Debug). platform: Target platform — Win32, Win64, Android64, iOSDevice64, iOSSimARM64, OSX64, OSXARM64, Linux64 (default Win32). For Cuttlefish always use Win32 unless explicitly building for mobile. target: MSBuild target — Build (default), Rebuild (clean+build), or Clean. studio_root: Optional Studio install (e.g. r"C:\Program Files (x86)\Embarcadero\Studio\37.0"). Defaults to the highest-version install detected. timeout: Seconds before the build is killed (default 600). Remote iOS/macOS/Linux builds can be slow on first run — bump to 1800+ if PAServer needs to re-deploy a large bundle. deep_clean: Nuke the platform's intermediate + bin dirs before building. None (default) auto-enables for Android/iOS/macOS/Linux Rebuild or Clean. True forces it on for any platform. False disables it. remote_profile: Name of the RAD Studio Connection Profile for PAServer. Required for iOS/macOS/Linux unless the .dproj pins a default. Ignored for Win32/Win64/Android. Example: "MyMacMini". If omitted on a PAServer platform, the tool auto-selects from registered Connection Profiles when exactly one is compatible — multiple matches force an explicit choice for safety (so a Linux Debug build can't accidentally hit a "production" PAServer host). deploy: Chain MSBuild's /t:Deploy after the requested target. Required to produce a packaged artifact on Android (APK), iOS (.app bundle + codesign), macOS (.app), and Linux (binary staged on remote). None (default) auto-enables for those platforms whenever target isn't Clean. False keeps the legacy "compile and link only" behaviour. Ignored for Win32/Win64. synthesize_ios_manifest: For iOS targets only. The IDE writes 4 DeployFile entries per Config × Platform on first deploy (Entitlements, InfoPList, LaunchScreen, ProjectOutput). Command- line Deploy can't synthesize them, so projects never IDE-deployed to iOS fail with cryptic "codesign … No such file" errors. Setting this True auto-adds the missing entries to the .dproj before Deploy runs, after writing a timestamped .bak backup. Default False — the build trace will report what's missing without mutating anything. Use check_ios_deploy to inspect without building.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configNoDebug
deployNo
targetNoBuild
timeoutNo
platformNoWin32
deep_cleanNo
dproj_pathYes
studio_rootNo
remote_profileNo
synthesize_ios_manifestNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.6

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries behavioral disclosure. It reveals side effects like deep-cleaning staging directories, modifying the .dproj file during synthesize_ios_manifest with a timestamped backup, PAServer reliance, path-resolution behavior, and a safe-guard that prevents cleaning outside the project tree.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear sections and front-loaded purpose, following with usage distinction, then detailed parameter-specific behavior. Given the tool's high complexity and many conditional paths, each sentence earns its place and supports correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers prerequisites, supported platforms, output path resolution, cleanup semantics, remote build behavior, deployment chaining, and iOS manifest caveats. Since output schema exists, the description does not need to explain return values, and no critical selection or invocation information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates thoroughly by documenting all 10 parameters beyond their schema types/defaults. Each parameter's meaning, auto-default behavior, valid contexts, and ignored contexts are explained (e.g., remote_profile required for PAServer, ignored for Win32/Android, deploy auto-enable rules).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: building an existing Delphi .dproj project via MSBuild + rsvars.bat, honoring the full RAD Studio configuration. It also explicitly contrasts itself with the sibling compile_delphi_project, making the distinction clear without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit and prominent: use this for real projects already on disk, not for generated templates, with a NOTE naming the sibling tool to use instead. It also gives when-to-use conditions for platform, deploy, deep_clean, remote_profile, and iOS manifest synthesis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools