Skip to main content
Glama
Basti-Fantasti

Delphi Build MCP Server

by Basti-Fantasti
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Delphi Build MCP Server

A Model Context Protocol (MCP) server that enables AI coding agents like Claude Code to compile Delphi projects programmatically.

Features

  • IDE-Identical Windows Builds: Windows targets (Win32/Win64/Win64x) compile via MSBuild, producing byte-identical output to the Delphi IDE — including icons, manifests, and DPI awareness

  • Hybrid Compilation: MSBuild for Windows targets, direct dcc for cross-compilation (Linux64/Android/Android64)

  • Minimal Configuration: Windows targets need only the Delphi installation path — MSBuild reads everything else from the .dproj

  • Automatic Configuration: Generate config from IDE build logs with multi-line parsing

  • Multi-Config Support: Generate unified config from multiple build logs (Debug/Release × Win32/Win64/Win64x/Linux64)

  • Extend Configuration: Add new platforms or libraries to existing config without regenerating

  • Smart Compilation: Reads .dproj files for build settings and compiler flags

  • Package Support: Compiles both application (.dpr) and package (.dpk) projects with correct output (.exe/.bpl)

  • Filtered Output: Returns only errors, filters out warnings and hints

  • Multi-Language Support: Parses both English and German compiler output

  • Response File Support: Handles command lines >8000 characters automatically

  • Cross-Platform: Supports Win32, Win64, Win64x (LLVM), Linux64, Android, and Android64

  • Environment Variables: Auto-expands ${USERNAME} in paths

  • MCP Compatible: Works with Claude Code, Cline, and other MCP clients

  • Network Transport: Streamable HTTP support for remote access (e.g., WSL-Ubuntu to Windows host)

  • WSL Interop: Use from WSL-Ubuntu via stdio through Windows Python or via Streamable HTTP

Related MCP server: Delphi Compiler MCP

Quick Start

1. Install

# Install UV if you haven't already
# Windows: powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
# macOS/Linux: curl -LsSf https://astral.sh/uv/install.sh | sh
# Or: pip install uv

cd delphi-build-mcp-server
uv venv
uv pip install -e .

2. Generate Configuration

In Delphi IDE:

  1. Tools > Options > Building > Show compiler progress > "Verbose"

  2. Build your project

  3. View > Messages > Right-click > Copy All

  4. Save to build.log

Then generate config:

Single Build Log (simple projects):

# Platform-specific config is generated by default (e.g., delphi_config_win64.toml)
uv run python -m src.config_generator build.log

# Generate generic delphi_config.toml instead
uv run python -m src.config_generator build.log --generic

Multiple Build Logs (multi-platform projects):

For projects targeting multiple platforms (Win32/Win64/Linux64), create build logs for each configuration:

  1. Build in IDE with each Platform/Config combination

  2. Save each build log separately (e.g., build_debug_win32.log, build_release_linux64.log)

  3. Generate config from all logs:

# Separate platform-specific config files (default)
uv run python -m src.multi_config_generator build_win32.log build_win64.log
# Creates: delphi_config_win32.toml, delphi_config_win64.toml

# Custom output directory for platform-specific files
uv run python -m src.multi_config_generator *.log -d ./configs/

# Single unified config instead of separate files
uv run python -m src.multi_config_generator build_win32.log build_win64.log --unified -o my_config.toml

# Disable environment variable substitution
uv run python -m src.multi_config_generator *.log --no-env-vars

Configuration Strategy:

Windows targets (Win32/Win64/Win64x) use MSBuild, which reads all compiler settings from the .dproj file. Only a minimal delphi_config.toml with the Delphi installation path is needed. Cross-compilation targets (Linux64/Android/Android64) still need full platform-specific config files.

Platform

Config File

Content

Win32/Win64/Win64x

delphi_config.toml

Minimal (only [delphi] section)

Linux64

delphi_config_linux64.toml

Full (paths, flags, SDK)

Android

delphi_config_android.toml

Full (paths, flags, NDK)

Android64

delphi_config_android64.toml

Full (paths, flags, NDK)

Config search order:

  1. DELPHI_CONFIG environment variable (explicit override)

  2. delphi_config_{platform}.toml (platform-specific)

  3. delphi_config.toml (generic fallback — Windows targets only)

Or use the Python API:

from src.config_generator import ConfigGenerator
from src.multi_config_generator import MultiConfigGenerator
from pathlib import Path

# Single build log
generator = ConfigGenerator()
result = generator.generate_from_build_log(
    build_log_path=Path("build.log"),
    output_path=Path("delphi_config.toml")
)

# Multiple build logs (recommended for multi-platform)
multi_gen = MultiConfigGenerator()
result = multi_gen.generate_from_build_logs(
    build_log_paths=["build_debug_win32.log", "build_release_win64.log", "build_debug_linux64.log"],
    output_path=Path("delphi_config.toml")
)
print(result.message)

3. Configure Claude Code

Edit %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "delphi-build": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\path\\to\\delphi-build-mcp-server",
        "main.py"
      ],
      "env": {
        "DELPHI_CONFIG": "C:\\path\\to\\delphi-build-mcp-server\\delphi_config.toml"
      }
    }
  }
}

Server Options

The server supports two transport modes:

Flag

Default

Description

--transport

stdio

Transport type: stdio or streamable-http

--host

0.0.0.0

Bind address (streamable-http only)

--port

8080

Listen port (streamable-http only)

Local (stdio, default):

uv run main.py

Network (Streamable HTTP):

uv run main.py --transport streamable-http
# Server listens on http://0.0.0.0:8080/mcp

Configure Claude Code in WSL-Ubuntu

Two options for using the Delphi MCP server from WSL-Ubuntu:

Option 1: stdio via WSL Interop (Simplest)

WSL can execute Windows binaries directly. This uses stdio transport through the Windows Python -- no HTTP server needed, no manual start. Claude Code manages the server lifecycle automatically.

Edit ~/.claude.json (or project-level .mcp.json) in WSL:

{
  "mcpServers": {
    "delphi-build": {
      "command": "/mnt/c/Users/<username>/path/to/delphi-build-mcp-server/.venv/Scripts/python.exe",
      "args": [
        "/mnt/c/Users/<username>/path/to/delphi-build-mcp-server/main.py"
      ],
      "env": {
        "DELPHI_CONFIG": "C:\\Users\\<username>\\path\\to\\delphi_config.toml"
      }
    }
  }
}

Note: The DELPHI_CONFIG path must use Windows-style paths since the server runs as a Windows process.

Option 2: Streamable HTTP (Network Transport)

Run the MCP server as a persistent HTTP service on Windows and connect from WSL over the network.

1. Start the MCP server on Windows:

cd C:\path\to\delphi-build-mcp-server
uv run main.py --transport streamable-http

To start the server automatically at logon, place start_mcp_server.bat (included in this repository) in your Windows Startup folder (Win+R → shell:startup).

2. Find your Windows host IP from WSL:

# Method 1: WSL gateway IP
cat /etc/resolv.conf | grep nameserver | awk '{print $2}'

# Method 2: Windows hostname
hostname -I  # run on Windows side

3. Configure Claude Code in WSL:

Edit ~/.claude.json (or project-level .mcp.json):

{
  "mcpServers": {
    "delphi-build": {
      "url": "http://<windows-host-ip>:8080/mcp"
    }
  }
}

Note: If the connection is refused, you may need to allow port 8080 through Windows Firewall:

netsh advfirewall firewall add rule name="Delphi MCP Server" dir=in action=allow protocol=TCP localport=8080

4. Use in Claude Code

Please compile my Delphi project at X:\MyProject\MyApp.dproj

Tools

compile_delphi_project

Compile a Delphi project and return parsed results.

Parameters:

  • project_path (required): Path to .dpr or .dproj file

  • force_build_all: Force rebuild all units

  • override_config: Override build config (Debug/Release)

  • override_platform: Override platform (Win32/Win64/Win64x/Linux64)

  • additional_search_paths: Extra search paths

  • additional_flags: Additional compiler flags

Returns:

  • success: Whether compilation succeeded

  • errors: List of compilation errors (warnings/hints filtered)

  • compilation_time_seconds: Time taken

  • output_executable: Path to compiled EXE

  • statistics: Compilation statistics

generate_config_from_build_log

Generate delphi_config.toml from a single IDE build log.

Parameters:

  • build_log_path (required): Path to build log file

  • output_config_path: Output file path (overrides default platform-specific naming)

  • use_platform_specific_name: Generate platform-specific filename (e.g., delphi_config_win64.toml) based on detected platform (default: true)

  • use_env_vars: Replace paths with ${USERNAME} (default: true)

Returns:

  • success: Whether generation succeeded

  • config_file_path: Path to generated config

  • statistics: Paths found and processed

  • detected_info: Delphi version, platform, build config

generate_config_from_multiple_build_logs

Generate configuration from multiple IDE build logs for different configurations and platforms. By default, creates separate platform-specific files (e.g., delphi_config_win32.toml, delphi_config_win64.toml).

Parameters:

  • build_log_paths (required): Array of paths to IDE build log files (e.g., Debug-Win32, Release-Win64, Debug-Linux64)

  • output_config_path: Output file path for unified config (only used when generate_separate_files=false)

  • generate_separate_files: Generate separate platform-specific config files (default: true). Set to false for a single unified config.

  • output_dir: Output directory for generated files (default: current directory)

  • use_env_vars: Replace paths with ${USERNAME} (default: true)

Returns:

  • success: Whether generation succeeded

  • config_file_path: Path to generated config(s)

  • build_logs_processed: Details of each processed log (path, config, platform, auto_detected)

  • statistics: Configs found, platforms found, total library paths, files generated

extend_config_from_build_log

Extend an existing delphi_config.toml with settings from a new IDE build log. Useful for adding support for new platforms (e.g., Win64x) or libraries without regenerating the entire configuration.

Parameters:

  • existing_config_path (required): Path to existing delphi_config.toml

  • build_log_path (required): Path to IDE build log file

  • output_config_path: Output path (default: overwrites existing)

  • use_env_vars: Replace paths with ${USERNAME} (default: true)

Returns:

  • success: Whether extension succeeded

  • config_file_path: Path to extended config

  • paths_added: Number of new paths added

  • paths_skipped: Number of duplicates skipped

  • platforms_added: List of new platforms (e.g., ["Win64x"])

  • settings_updated: Count of settings updated per section

Documentation

Project Structure

delphi-build-mcp-server/
|-- main.py                       # MCP server entry point (stdio + streamable-http)
|-- src/
|   |-- models.py                 # Pydantic data models
|   |-- buildlog_parser.py        # Parse IDE build logs
|   |-- dproj_parser.py           # Parse .dproj files
|   |-- config.py                 # Load TOML configuration
|   |-- output_parser.py          # Parse dcc compiler output
|   |-- msbuild_output_parser.py  # Parse MSBuild output (extracts _PasCoreCompile)
|   |-- msbuild_compiler.py       # MSBuild compilation for Windows targets
|   |-- rsvars_parser.py          # Parse rsvars.bat for MSBuild environment
|   |-- config_generator.py       # Generate TOML configs (single log)
|   |-- multi_config_generator.py # Generate TOML configs (multi-log)
|   |-- config_extender.py        # Extend existing TOML configs
|   +-- compiler.py               # Direct dcc compilation for cross-compilation
|-- tests/                        # Unit tests
|-- start_mcp_server.bat          # Auto-start script for Windows (shell:startup)
|-- test_stdio_wsl.sh             # Test stdio transport from WSL
|-- test_http_transport.sh        # Test Streamable HTTP transport (bash)
|-- test_http_transport.bat       # Test Streamable HTTP transport (Windows)
|-- delphi_config.toml.template   # Configuration template
|-- pyproject.toml                # Python project config
|-- QUICKSTART.md                 # Quick start guide
+-- DOCUMENTATION.md              # Complete documentation

Requirements

  • Python 3.10+

  • Delphi 11, 12, or 13

  • MCP-compatible client (Claude Code, Cline, etc.)

How It Works

Note: The server automatically handles response files for projects with 80+ library paths (command lines >8000 chars) and parses both English and German compiler output.

1. AI Agent calls compile_delphi_project
   |
   v
2. Parse .dproj file to determine platform
   |
   v
3. Route based on platform:
   |
   +---> Windows (Win32/Win64/Win64x):
   |     - Load minimal config (delphi.root_path only)
   |     - Set up MSBuild environment from rsvars.bat
   |     - Execute msbuild.exe (IDE-identical output)
   |     - Parse _PasCoreCompile section for errors
   |
   +---> Cross-compilation (Linux64/Android/Android64):
         - Load full platform-specific config
         - Build dcc compiler command
         - Execute dcc32/dcc64/dcclinux64/dccaarm64
         - Parse compiler output for errors
   |
   v
4. Return structured result to AI

Example Usage

Compile a Project

from src.compiler import DelphiCompiler
from pathlib import Path

compiler = DelphiCompiler()
result = compiler.compile_project(
    project_path=Path("X:/MyProject/MyApp.dproj")
)

if result.success:
    print(f"[OK] Compilation successful: {result.output_executable}")
else:
    print(f"[FAIL] Compilation failed with {len(result.errors)} errors:")
    for error in result.errors:
        print(f"  {error.file}({error.line},{error.column}): {error.message}")

Generate Config from Build Log

from src.config_generator import ConfigGenerator
from pathlib import Path

generator = ConfigGenerator(use_env_vars=True)
result = generator.generate_from_build_log(
    build_log_path=Path("build.log"),
    output_path=Path("delphi_config.toml")
)

print(f"[OK] {result.message}")
print(f"  Detected: Delphi {result.detected_info.delphi_version}")
print(f"  Platform: {result.detected_info.platform}")
print(f"  Paths found: {result.statistics['unique_paths']}")

Generate Multi-Platform Config from Multiple Build Logs

from src.multi_config_generator import MultiConfigGenerator
from pathlib import Path

generator = MultiConfigGenerator(use_env_vars=True)
result = generator.generate_from_build_logs(
    build_log_paths=[
        "build_debug_win32.log",
        "build_release_win32.log",
        "build_debug_linux64.log",
        "build_release_linux64.log"
    ],
    output_path=Path("delphi_config.toml")
)

print(f"[OK] {result.message}")
print(f"  Configs: {result.statistics['configs_found']}")
print(f"  Platforms: {result.statistics['platforms_found']}")
print(f"  Total paths: {result.statistics['total_library_paths']}")

Extend Existing Config with New Platform

from src.config_extender import ConfigExtender
from pathlib import Path

# Extend existing config with Win64x platform support
extender = ConfigExtender(use_env_vars=True)
result = extender.extend_from_build_log(
    existing_config_path=Path("delphi_config.toml"),
    build_log_path=Path("build_win64x.log")
)

print(f"[OK] {result.message}")
print(f"  New platforms: {result.platforms_added}")
print(f"  Paths added: {result.paths_added}")
print(f"  Paths skipped (duplicates): {result.paths_skipped}")

Or via CLI:

uv run python -m src.config_extender delphi_config.toml build_win64x.log
uv run python -m src.config_extender delphi_config.toml build_win64x.log -o extended_config.toml

Troubleshooting

"Configuration file not found"

Generate it from a build log:

uv run python -m src.config_generator build.log

"Unit not found"

Regenerate config from a fresh IDE build log that includes all dependencies.

"Compiler not found"

Verify delphi.root_path in delphi_config.toml points to your Delphi installation.

Development

Install Development Dependencies

uv pip install -e ".[dev]"

Run Tests

uv run pytest

Test Sample Projects

Two sample projects are included for testing:

# Test successful compilation
uv run python test_compile_samples.py

  • sample/working/Working.dproj - Compiles successfully

  • sample/broken/Broken.dproj - Intentionally has errors for testing error parsing

Code Formatting

uv run black src/
uv run ruff check src/

Contributing

Contributions are welcome! Please see CONTRIBUTING.md for guidelines.

License

MIT License - see LICENSE file for details.

Support

Acknowledgments

Available Tools

4 tools
compile_delphi_projectA

Compile a Delphi project (.dpr or .dproj file) and return parsed results. For Windows targets (Win32/Win64/Win64x), uses MSBuild for IDE-identical output including icons, manifests, and DPI awareness. For cross-compilation targets (Linux64/Android/Android64), uses direct dcc compiler invocation. Returns only compilation errors, filtering out warnings and hints.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_pathYesAbsolute path to .dpr or .dproj file
force_build_allNoForce rebuild all units (adds -B flag)
override_configNoOverride active build config (e.g., "Debug", "Release")
override_platformNoOverride active platform (e.g., "Win32", "Win64", "Linux64", "Android", "Android64")
additional_search_pathsNoExtra unit search paths to add
additional_flagsNoAdditional compiler flags to append

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must disclose all behavioral traits. It explains the compilation method per target and that it filters out warnings/hints. However, it does not mention side effects, permissions, error handling, or the format of 'parsed results', leaving gaps.

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 two sentences: the first states the core purpose, the second provides critical behavioral details. Every sentence is informative and no redundant words. It is optimally concise.

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

Completeness4/5

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

Given 6 parameters and no output schema, the description covers core behavior and target-specific compilation. It lacks description of return value format and potential error outputs, but the parameter schema is fully documented, so the description is largely complete.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema parameter descriptions; it only restates behavior for some parameters implicitly through target distinctions.

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 clearly specifies the verb 'compile', the resource 'Delphi project (.dpr or .dproj file)', and states that it returns parsed results. It distinguishes behavior by target platform, which adds specificity. The sibling tools have different purposes (config generation), so no confusion.

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

Usage Guidelines4/5

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

The description provides context on when to use this tool: for compiling Delphi projects. It explains different behavior for Windows vs cross-compilation targets. However, it lacks explicit 'when not to use' guidance or mention of alternatives, though siblings are unrelated.

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

extend_config_from_build_logA

Extend an existing delphi_config.toml with settings from a new IDE build log. Useful for adding support for new platforms (e.g., Win64x) or libraries without regenerating the entire configuration. Intelligently merges new paths while preserving existing settings and avoiding duplicates.

ParametersJSON Schema
NameRequiredDescriptionDefault
existing_config_pathYesAbsolute path to existing delphi_config.toml file
build_log_pathYesAbsolute path to IDE build log file
output_config_pathNoOutput path for extended config file (default: overwrites existing)
use_env_varsNoReplace user paths with ${USERNAME} environment variable

TDQS

A3.8/5.0
Behavior3/5

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

Describes merging behavior and preservation of settings, but lacks details on error handling, idempotency, or side effects. No annotations to supplement.

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?

Two efficient sentences, front-loaded with the primary action and followed by context and behavior, with no wasted words.

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

Completeness2/5

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

Lacks information about return values, error handling, and what happens on invalid input or malformed files. Without an output schema, the description should cover these aspects.

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

Parameters3/5

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

Schema covers all parameters with descriptions; the description adds no extra meaning beyond what is already in the schema for each parameter.

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 clearly states the tool extends an existing config file with new build log settings, distinguishing it from sibling tools that generate configurations from scratch.

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

Usage Guidelines4/5

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

Provides explicit use case (adding platforms/libraries without regeneration) and mentions intelligent merging, but does not explicitly list when not to use or alternative tools.

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

generate_config_from_build_logA

Generate delphi_config.toml file automatically by parsing an IDE build log. For Windows targets, generates a minimal config with only the Delphi installation path (MSBuild handles all other settings). For cross-compilation targets (Linux64/Android), generates a full config with all library paths and compiler settings.

ParametersJSON Schema
NameRequiredDescriptionDefault
build_log_pathYesAbsolute path to IDE build log file
output_config_pathNoOutput path for generated config file. If not specified, generates platform-specific filename (e.g., delphi_config_win32.toml) by default.
use_platform_specific_nameNoGenerate platform-specific filename (e.g., delphi_config_win64.toml) based on detected platform. Set to false for generic delphi_config.toml. Ignored if output_config_path is specified.
use_env_varsNoReplace user paths with ${USERNAME} environment variable

TDQS

A3.7/5.0
Behavior3/5

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

Provides target-specific behavior details (minimal vs full config) beyond annotations, but omits important aspects like file overwrite behavior, error handling, and permissions.

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?

Two efficient sentences, front-loaded with purpose followed by platform differentiation; no wasted words.

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

Completeness3/5

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

Covers main functionality and platform differences, but lacks details on output format, success/failure behavior, and usage context relative to sibling tools.

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

Parameters3/5

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

Input schema covers all parameters (100% coverage), and the description adds no additional parameter explanation, meeting baseline but not exceeding.

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?

Clearly states the tool generates a config file from an IDE build log, and distinguishes behavior for Windows vs cross-compilation targets.

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

Usage Guidelines3/5

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

Implies usage for single build log config generation, but lacks explicit guidance on when not to use or comparison with sibling tools like extend_config_from_build_log.

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

generate_config_from_multiple_build_logsA

Generate delphi_config.toml file from multiple IDE build logs for different configurations and platforms. By default, creates separate platform-specific config files (e.g., delphi_config_win32.toml, delphi_config_win64.toml). Use this when you have build logs from multiple configurations (Debug/Release) and/or platforms (Win32/Win64/Linux64/Android/Android64).

ParametersJSON Schema
NameRequiredDescriptionDefault
build_log_pathsYesArray of absolute paths to IDE build log files (e.g., Debug-Win32, Release-Win64, Debug-Linux64, Debug-Android64)
output_config_pathNoOutput path for unified config file. Only used when generate_separate_files=False.delphi_config.toml
generate_separate_filesNoGenerate separate platform-specific config files (default). Set to false for a single unified config.
output_dirNoOutput directory for generated platform-specific files. Defaults to current directory..
use_env_varsNoReplace user paths with ${USERNAME} environment variable

TDQS

A4/5.0
Behavior3/5

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

Given no annotations, description carries full burden. It covers default behavior (separate files) and key parameters, but lacks details on file overwriting, error handling, or output structure. Adequate but not rich.

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?

Two concise sentences: first states purpose and default behavior, second gives usage guidance. Front-loaded with key information, no wasted words.

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

Completeness4/5

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

Covers main use case and key behaviors adequately given high schema coverage. Lacks output format details and error behavior, but sufficient for most agents.

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

Parameters3/5

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

Input schema descriptions cover all 5 parameters fully (100% coverage). The tool description adds minimal additional context beyond summarizing the schema, so baseline score applies.

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?

Description clearly identifies the action (generate), resource (delphi_config.toml), and context (from multiple IDE build logs). Differentiates from siblings by specifying 'multiple' configurations and platforms, contrasting with the singular version.

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

Usage Guidelines4/5

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

Explicitly states when to use: when you have build logs from multiple configurations and/or platforms. Implicitly suggests not using it for single logs (sibling tool). Could be improved by naming alternatives directly.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv2.0.0
    • Changedcompile_delphi_project1 field changed
      • changedInput schema / properties / override_platform / description
        Previous value: -"Override active platform (e.g., \"Win32\", \"Win64\")"New value: +"Override active platform (e.g., \"Win32\", \"Win64\", \"Linux64\", \"Android\", \"Android64\")"
    • Changedgenerate_config_from_multiple_build_logs1 field changed
      • changedInput schema / properties / build_log_paths / description
        Previous value: -"Array of absolute paths to IDE build log files (e.g., Debug-Win32, Release-Win64, Debug-Linux64)"New value: +"Array of absolute paths to IDE build log files (e.g., Debug-Win32, Release-Win64, Debug-Linux64, Debug-Android64)"
  2. 4 tool updatesv1.6.0
    • First observedcompile_delphi_project
    • First observedextend_config_from_build_log
    • First observedgenerate_config_from_build_log
    • First observedgenerate_config_from_multiple_build_logs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct role: compile a project, generate a config from a single build log, generate configs from multiple build logs, and extend an existing config. The descriptions clearly separate these cases, so an agent should rarely confuse them.

Naming Consistency5/5

All tool names use consistent snake_case and follow a clear verb-object pattern. The config tools share the 'config_from_build_log' suffix, which makes their relationship and differences immediately obvious.

Tool Count5/5

Four tools is well-scoped for a Delphi build server: one compilation tool and three config-generation variants. Each tool serves a distinct, non-redundant purpose in the workflow.

Completeness4/5

The core workflow of compiling and generating/ extending configuration from build logs is covered. There is no tool to inspect or validate the generated config, but that is an ancillary gap rather than a workflow dead end.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers