Skip to main content
Glama
sevenfifty777

DCS Lua Runner MCP Server

by sevenfifty777
OverviewSchemaRelated ServersScoreDiscussions
Local

DCS Lua Runner MCP Server

An MCP (Model Context Protocol) server that enables AI assistants to interact with DCS World (Digital Combat Simulator) in real-time through chat.

Features

This MCP server provides the following tools for AI interaction with DCS:

Tools Available

  1. execute_lua - Execute arbitrary Lua code on DCS server

    • Execute custom Lua scripts

    • Choice of mission or GUI environment

    • Returns execution results

  2. get_mission_info - Get current mission information

    • Mission time

    • Theatre/map name

    • Mission date

  3. get_player_info - Get player aircraft information

    • Aircraft name and type

    • Position (x, y, z coordinates)

    • Altitude

    • Speed

    • Heading

  4. get_all_units - List all units in the mission

    • Filter by coalition (red, blue, neutral, or all)

    • Unit names, types, positions

    • Coalition affiliations

  5. spawn_unit - Spawn new units in the mission

    • Ground units or vehicles

    • Specify position, heading, coalition

    • Custom unit names

  6. send_message - Display messages in DCS

    • Send text messages to all players

    • Configurable display duration

  7. get_theatre_info - Get theatre/map information

    • Current map name

    • Theatre details

  8. get_aircraft_list - List all aircraft in mission

    • All airborne units

    • Positions and altitudes

    • Coalition information

  9. convert_coordinates - Convert real-world coordinates to DCS

    • Convert Lat/Long (decimal degrees) to DCS X/Z coordinates

    • Optional altitude parameter

    • Uses the theatre's native coord.LLtoLO DCS API

  10. convert_dcs_to_ll - Convert DCS coordinates to Lat/Long

    • Convert DCS X/Z to real-world Latitude/Longitude

    • Optional Y/altitude parameter

    • Uses the theatre's native coord.LOtoLL DCS API

Related MCP server: TAK Server MCP

Prerequisites

  1. DCS World installed with DCS Fiddle server running

  2. Node.js installed (for running the MCP server)

Configuration

The MCP server reads settings from dcs_lua_runner_settings.json in the following priority order:

  1. Environment Variable (if set): Path specified in DCS_SETTINGS_PATH

  2. MCP Server Directory (default): dcs_lua_runner_settings.json in the same folder as the MCP server

  3. Fallback Defaults: If no settings file is found, uses default localhost configuration

Quick Setup

  1. Copy the template file:

    cp dcs_lua_runner_settings.json.template dcs_lua_runner_settings.json

  2. Edit the settings file with your DCS server details (the defaults work for most local setups)

The MCP server will automatically find and load the settings file from its own directory.

Settings Used

  • server_address - DCS server address for remote connections

  • server_port - Port for mission environment (default: 12080)

  • server_address_gui - GUI environment server address

  • server_port_gui - Port for GUI environment (default: 12081)

  • use_https - Whether to use HTTPS

  • web_auth_username - Username for authentication

  • web_auth_password - Password for authentication

  • run_code_locally - Execute on local server (127.0.0.1)

  • run_in_mission_env - Execute in mission vs GUI environment

Installation

Method 1: Direct Installation (Pre-built)

The release zip already contains the pre-built build/index.js — no Node.js build step required.

  1. Extract the release zip (e.g. dcs-lua-runner-mcp-v1.1.0.zip) to your preferred location, e.g.:

    C:\dcs-lua-runner-mcp\

  2. Run the installer script — open PowerShell, navigate to the extracted folder and run:

    .\install-mcp-agent.ps1

    The script walks you through two steps automatically:

    Step 1 — DCS Server Settings

    • Asks whether DCS runs on the same machine (local) or on a remote IP

    • Prompts for port, username, and password (current/template values shown in brackets — press Enter to keep)

    • Saves the result to dcs_lua_runner_settings.json

    • Also patches dcs-fiddle-server.lua with IP, port, username and password — no need to edit it separately

    Step 2 — Agent Registration

    • Shows a numbered menu of supported agents with their config status

    • Enter one or more numbers separated by commas or spaces, or type all

    • Type skip (or press Enter with no input) to skip agent registration entirely

    • Patches each selected agent config file (creates the file if it doesn't exist yet)

    1. Claude Desktop
2. Cline (VS Code extension)
3. GitHub Copilot Chat (VS Code)
4. Cursor
5. Windsurf
6. Claude Code CLI
7. GitHub Copilot CLI

    Tip: You can skip the interactive prompts entirely with flags:

    # Configure specific agents (e.g. Copilot Chat + Cline)
.\install-mcp-agent.ps1 -AgentIds 2,3

# Configure all agents at once
.\install-mcp-agent.ps1 -All

# Skip agent registration (only update settings + fiddle script)
.\install-mcp-agent.ps1 -SkipAgents

# Point to a build in a custom location
.\install-mcp-agent.ps1 -ServerPath "D:\tools\dcs-mcp\build\index.js"

  3. Install the DCS server script — copy dcs-fiddle-server.lua into your DCS mission scripts or into the DCS Scripts\Hooks folder and load it (see DCS Server Script Installation).

  4. Restart your agent (reload VS Code, restart Claude Desktop, etc.) to apply the configuration changes.

Method 2: Installation from GitHub

  1. Clone the repository:

    git clone https://github.com/sevenfifty777/dcs-lua-runner-mcp.git
cd dcs-lua-runner-mcp

  2. Install dependencies:

    npm install

  3. Build the project:

    npm run build

  4. Configure settings and register agents:

    Option A — Automatic (recommended): Run the installer script, which handles everything in one go:

    .\install-mcp-agent.ps1

    The script will:

    • Prompt for DCS server settings and save dcs_lua_runner_settings.json

    • Patch dcs-fiddle-server.lua with the same values automatically

    • Let you pick which agents to register from a numbered menu (type skip to skip this step)

    Option B — Manual:

    Copy the template and fill in your DCS server details:

    cp dcs_lua_runner_settings.json.template dcs_lua_runner_settings.json

    Edit dcs_lua_runner_settings.json:

    {
  "server_address": "127.0.0.1",
  "server_port": 12080,
  "server_address_gui": "127.0.0.1",
  "server_port_gui": 12081,
  "use_https": false,
  "web_auth_username": "your_username",
  "web_auth_password": "your_password",
  "run_code_locally": true,
  "run_in_mission_env": true,
  "return_display_format": "lua"
}

    Then update your agent's MCP config file to point to build/index.js. Place dcs_lua_runner_settings.json in the same directory as the MCP server so it is found automatically.

    For Cline (VS Code) — edit %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json:

    {
  "mcpServers": {
    "dcs-lua-runner-mcp": {
      "command": "node",
      "args": ["C:/absolute/path/to/dcs-lua-runner-mcp/build/index.js"]
    }
  }
}

    For Claude Desktop — edit %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

    {
  "mcpServers": {
    "dcs-lua-runner-mcp": {
      "command": "node",
      "args": ["C:/absolute/path/to/dcs-lua-runner-mcp/build/index.js"]
    }
  }
}

    For GitHub Copilot Chat (VS Code) — edit %APPDATA%\Code\User\mcp.json:

    {
  "servers": {
    "dcs-lua-runner-mcp": {
      "command": "node",
      "args": ["C:/absolute/path/to/dcs-lua-runner-mcp/build/index.js"],
      "type": "stdio"
    }
  }
}

    For GitHub Copilot CLI — edit %USERPROFILE%\.copilot\mcp-config.json:

    {
  "mcpServers": {
    "dcs-lua-runner-mcp": {
      "command": "node",
      "args": ["C:/absolute/path/to/dcs-lua-runner-mcp/build/index.js"],
      "type": "stdio"
    }
  }
}

    Custom settings path — if dcs_lua_runner_settings.json lives elsewhere, pass its path via environment variable:

    {
  "mcpServers": {
    "dcs-lua-runner-mcp": {
      "command": "node",
      "args": ["C:/absolute/path/to/dcs-lua-runner-mcp/build/index.js"],
      "env": {
        "DCS_SETTINGS_PATH": "C:/custom/path/to/dcs_lua_runner_settings.json"
      }
    }
  }
}

  5. Install the DCS server script — copy dcs-fiddle-server.lua into your DCS mission scripts or into the DCS Scripts folder and load it (see DCS Server Script Installation).

  6. Restart your agent (reload VS Code, restart Claude Desktop, etc.)

  7. Test the connection:

    Ask your AI assistant: "What's the current mission time in DCS?"

Verification

After installation, verify the MCP server is working:

  1. Check that build/index.js exists

  2. Ensure DCS World is running with DCS Fiddle server

  3. Ask your AI assistant to get mission info

  4. Check MCP server logs in your client for any errors

Usage Examples

Once the MCP server is running, you can ask your AI assistant to interact with DCS:

Get Mission Information

"What's the current mission time in DCS?"
"What theatre/map am I flying in?"

Get Player Information

"Where is my aircraft?"
"What's my current altitude and speed?"

Spawn Units

"Spawn a T-72B tank at coordinates x=100000, z=200000 for the red coalition"
"Create an M-1 Abrams at position 150000, 250000 facing north"

Send Messages

"Send a message to all players saying 'Mission starting in 5 minutes'"

Execute Custom Lua

"Execute this Lua code in DCS: return timer.getTime()"
"Run this script to get all blue coalition units"

List Units and Aircraft

"Show me all units in the mission"
"List all red coalition aircraft"
"What aircraft are currently in the mission?"

Convert Coordinates

"Convert latitude 41.123, longitude 44.987 to DCS coordinates"
"What are the DCS X/Z coordinates for lat 51.5, lon 37.2?"
"Convert DCS coordinates X=100000, Z=200000 to latitude/longitude"
"What is the real-world position of the unit at DCS X=50000, Z=150000?"

DCS Setup Requirements

⚠️ Security Notice: Setting up DCS Fiddle requires disabling DCS sandboxing and, optionally, exposing a network port. Read DCS_Setup_Risks.md for a full risk assessment and mandatory security measures before proceeding.

1. DCS Fiddle Server Installation

Step 1 — Locate your Saved Games folder

DCS uses a folder under Windows Saved Games to store user scripts. The exact name depends on your DCS branch:

DCS Branch

Saved Games Folder

DCS World (stable)

%USERPROFILE%\Saved Games\DCS

DCS World OpenBeta

%USERPROFILE%\Saved Games\DCS.openbeta

Open File Explorer and navigate to the correct path, e.g.:

C:\Users\<YourUser>\Saved Games\DCS

Step 2 — Create the Hooks folder (if it does not exist)

Inside your Saved Games DCS folder, create the following folder structure if it is not already there:

Saved Games\DCS\Scripts\Hooks\

On Windows you can do this from PowerShell:

New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\Saved Games\DCS\Scripts\Hooks"

For OpenBeta replace DCS with DCS.openbeta.

Step 3 — Copy the server script

Copy dcs-fiddle-server.lua from this repository into the Hooks folder:

Copy-Item ".\dcs-fiddle-server.lua" "$env:USERPROFILE\Saved Games\DCS\Scripts\Hooks\"

The final path should look like:

%USERPROFILE%\Saved Games\DCS\Scripts\Hooks\dcs-fiddle-server.lua

Step 4 — Verify the script is loaded

After launching DCS, open %USERPROFILE%\Saved Games\DCS\Logs\dcs.log and search for:

DCS Fiddle successfully initialized

If you see this line the server is running and listening on ports 12080 (mission environment) and 12081 (GUI environment).

Note: The Hooks folder is loaded by DCS at startup for both the main menu (GUI environment) and in-mission. You do not need to add anything to autoexec.cfg.

2. DCS Desanitization

⚠️ Security Warning: This step disables DCS sandboxing and grants scripts full system access. See DCS_Setup_Risks.md for the full risk details and how to restore security afterwards.

Edit DCS_INSTALL\Scripts\MissionScripting.lua and comment out these two lines:

--  _G['require'] = nil      -- comment this out
    _G['loadlib'] = nil
--  _G['package'] = nil      -- comment this out

3. Start DCS

  1. Launch DCS World

  2. The DCS Fiddle server will start automatically

  3. Verify the server is running (check DCS.log for "DCS Fiddle successfully initialized")

Troubleshooting

Connection Errors

Error: "Connection refused - check if DCS Fiddle server is running"

  • Solution: Ensure DCS is running and DCS Fiddle server is installed correctly

Error: "Request timeout - check server connection"

  • Solution: Check if DCS Fiddle server is bound to the correct address/port

  • Verify firewall settings if using remote connections

Authentication Errors

Error: Unauthorized (401)

  • Solution: Check username/password in dcs_lua_runner_settings.json

  • Ensure authentication settings match DCS Fiddle server configuration

Execution Errors

Error: "No player found"

  • Solution: Ensure you're in a mission with a player-controlled aircraft

  • Try switching between mission and GUI environments

Error: Lua execution errors

  • Solution: Check Lua syntax and DCS API availability

  • Some functions only work in mission environment

Testing with MCP Inspector

The MCP Inspector is a developer tool that allows you to test and debug your MCP server interactively before integrating it with an AI client.

Running the Inspector

  1. Ensure the project is built:

    npm run build

  2. Start the MCP Inspector:

    npm run inspector

  3. Using the Inspector:

    • The inspector will open in your default web browser

    • You'll see an interactive GUI showing:

      • Available Tools: List of all 10 DCS interaction tools

      • Tool Parameters: Input fields for each tool's parameters

      • Request/Response: Real-time display of MCP communication

      • Test Results: Output from each tool execution

  4. Testing Individual Tools:

    • Select a tool from the list (e.g., get_mission_info)

    • Fill in required parameters (if any)

    • Click "Execute" to test the tool

    • View the response in JSON format

  5. Example Test Scenarios:

    • Test connection: Use get_mission_info to verify DCS connection

    • Test Lua execution: Use execute_lua with simple code like return "Hello from DCS"

    • Test spawning: Use spawn_unit with test coordinates

    • Debug errors: View detailed error messages and stack traces

Inspector Benefits

  • No AI client needed: Test without configuring Cline or Claude Desktop

  • Interactive debugging: See requests and responses in real-time

  • Parameter validation: Verify tool inputs before integration

  • Quick iteration: Test changes immediately after rebuilding

Notes

  • The inspector runs the MCP server in a test environment

  • You still need DCS World running with the Fiddle server for actual DCS interaction

  • The inspector uses the same dcs_lua_runner_settings.json configuration

Development

Building from Source

cd C:\{your_path}\dcs-lua-runner-mcp
npm install
npm run build

Project Structure

dcs-lua-runner-mcp/
├── src/
│   └── index.ts          # Main MCP server implementation
├── build/
│   └── index.js          # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.md

Adding New Tools

To add new DCS interaction tools:

  1. Add tool definition to ListToolsRequestSchema handler

  2. Implement tool logic in CallToolRequestSchema handler

  3. Rebuild: npm run build

Security Considerations

  • Local Execution: By default, executes on 127.0.0.1 (localhost only)

  • Remote Execution: Requires authentication (username/password)

  • Code Validation: All Lua code is base64-encoded before transmission

  • DCS Security: Requires DCS desanitization (understand the risks!)

License

MIT License - Based on the DCS Lua Runner GUI project

Credits

  • Original DCS Fiddle: JonathanTurnock and john681611

  • DCS Lua Runner VSCode Extension: omltcat

  • GUI Implementation: Created for standalone Windows application

  • Model Context Protocol: MCP SDK by Anthropic

Support

For issues related to:

  • MCP Server: Check the build output and MCP settings

  • DCS Connection: Verify DCS Fiddle server installation

  • Lua Execution: Check DCS.log for detailed error messages

LobeHub

MCP Badge

Available Tools

10 tools
convert_coordinatesA

Convert real-world Latitude/Longitude coordinates to DCS X/Z coordinates using the theatre's coordinate system

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYesLatitude in decimal degrees (e.g. 41.12345)
longitudeYesLongitude in decimal degrees (e.g. 44.98765)
altitudeNoAltitude in meters above sea level (optional, default 0)

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes a conversion operation but does not specify behavioral traits such as whether it's read-only, requires authentication, or has any side effects. The description is minimal but not misleading.

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 a single sentence that is front-loaded with the action and key components. No extraneous information is included.

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?

For a simple conversion tool, the description is minimally adequate. However, it lacks details about the output format, coordinate system specifics, and potential errors. Given no output schema, more completeness would be beneficial.

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 each parameter has a description in the schema. The tool description adds no additional semantic information beyond the schema. Baseline score of 3 is appropriate.

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 converts Latitude/Longitude to DCS X/Z coordinates, using the theatre's coordinate system. It distinguishes itself from the sibling tool 'convert_dcs_to_ll' which does the reverse.

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 implies usage when real-world coordinates need to be converted to DCS coordinates. While it doesn't explicitly state when not to use it or provide alternatives, the sibling tool name 'convert_dcs_to_ll' offers context for the reverse operation.

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

convert_dcs_to_llB

Convert DCS X/Z coordinates to real-world Latitude/Longitude

ParametersJSON Schema
NameRequiredDescriptionDefault
xYesDCS X coordinate (meters)
zYesDCS Z coordinate (meters)
yNoDCS Y coordinate / altitude in meters (optional, default 0)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations and no output schema, the description carries the full burden. It does not disclose behavioral traits such as coordinate system assumptions, accuracy, units of output, or whether the conversion is reversible. It only states the basic transformation.

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

Conciseness4/5

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

The description is a single sentence with zero wasted words. It is front-loaded with the core purpose. However, it is almost too brief, lacking detail that could be concise if structured.

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?

Given the tool's complexity (3 parameters, no output schema, no annotations), the description is insufficient. It does not explain the output format (e.g., decimal degrees), any prerequisites, or potential errors, leaving gaps for an AI agent.

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 description coverage is 100%, so the schema already explains each parameter. The description adds no new meaning beyond what is in the schema, just repeats the conversion intent. Baseline is 3.

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 converts DCS X/Z coordinates to real-world Latitude/Longitude. It specifies the verb 'convert' and the resources 'DCS X/Z coordinates' and output 'real-world Latitude/Longitude', distinguishing it from the sibling tool 'convert_coordinates' which is more generic.

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

Usage Guidelines2/5

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 vs alternatives like 'convert_coordinates'. The description only states the conversion purpose without context or exclusions.

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

execute_luaA

Execute arbitrary Lua code on DCS server. Returns the result of the executed code. Use this for custom operations not covered by other tools.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesLua code to execute in DCS
environmentNoDCS environment to execute in (mission for in-game, gui for main menu)mission

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure for a potentially dangerous code execution tool. It only states basic functionality and does not mention risks like server crashes, security implications, side effects, or execution constraints, which is a critical omission.

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 concise sentences with no fluff. Every sentence adds value: first states function, second guides usage. It is front-loaded and efficient.

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?

For a generic code execution tool with no output schema, the description is too minimal. It does not explain the return format, error handling, execution timeout, or potential side effects. More context is needed for safe and effective use.

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%, and the description does not add any new information about parameters beyond what is in the schema. The baseline of 3 is appropriate since the schema already fully documents the parameters.

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 that the tool executes arbitrary Lua code on the DCS server and returns the result. It explicitly positions itself as a fallback for custom operations not covered by other tools, distinguishing it from the specific sibling tools.

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 advises using this tool 'for custom operations not covered by other tools,' which provides clear guidance on when to use it versus alternatives. However, it lacks explicit when-not-to-use scenarios, such as warnings against using it for tasks that are better served by existing tools.

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

get_aircraft_listA

Get a list of all aircraft in the mission with their status

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. The verb 'Get' implies a non-destructive read operation, which is appropriate. However, it lacks disclosure of any side effects, authentication requirements, or rate limits. For a simple list retrieval, this is minimally adequate but could be improved with explicit mention of idempotence.

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?

Single sentence that is front-loaded with the essential action and resource. No wasted words; every part of the sentence adds value.

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?

For a simple tool with no parameters and no output schema, the description adequately conveys the purpose and scope. It does not describe the return format or what 'status' entails, but given the tool's simplicity and the absence of complexity, it is largely complete.

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

Parameters4/5

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

There are zero parameters, making schema coverage 100% vacuously. The description does not need to add parameter semantics, and the baseline for no parameters is 4. No information is missing.

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 specifies the action 'Get', the resource 'list of all aircraft', and the scope 'in the mission' with what's included ('with their status'). It distinctly separates this tool from siblings like 'get_all_units' (all units) and 'get_mission_info' (mission metadata).

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?

While not explicitly stating when to use or exclude, the description implies its role for aircraft status retrieval versus sibling tools like 'get_all_units' which cover all units. The context of a dedicated aircraft list provides implicit guidance for selecting this tool over broader alternatives.

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

get_all_unitsA

Get a list of all units in the mission with their properties (coalition, type, position, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
coalitionNoFilter by coalitionall

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description carries full burden. It states what is returned (list with properties), but does not disclose potential performance concerns, limitations, or whether it is read-only (though implied).

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 a single, concise sentence that efficiently conveys the tool's purpose and output without unnecessary 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?

For a simple tool with one optional parameter and no output schema, the description is fairly complete—it states the resource, filtering, and example properties. It could specify if all properties or a subset are returned, but 'etc.' implies more.

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% with a single parameter described. The description adds context that the parameter filters by coalition and that the default is all units, but otherwise adds minimal value beyond the schema.

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 verb 'Get', the resource 'all units', and lists example properties (coalition, type, position, etc.). It distinguishes from sibling tools like get_aircraft_list which is aircraft-specific.

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?

The description implies usage for retrieving all units, but does not explicitly differentiate from siblings or explain when to use this tool vs. get_aircraft_list or get_player_info.

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

get_mission_infoA

Get current mission information including time, theatre, mission name, and weather conditions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided, and the description only implies a read-only operation without explicit behavioral disclosures such as safety or side effects.

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?

A single, front-loaded sentence that efficiently conveys the tool's purpose without extraneous 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?

Given zero parameters and no output schema, the description adequately explains what the tool returns, though it could elaborate on the format.

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

Parameters4/5

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

The tool has zero parameters, and the description adds value by explaining the output content, which is the primary purpose.

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 retrieves mission information and lists specific data points (time, theatre, mission name, weather), distinguishing it from sibling tools like get_theatre_info.

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

Usage Guidelines2/5

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, nor does it mention when not to use it.

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

get_player_infoA

Get information about the player's aircraft including position, altitude, speed, heading, and fuel

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided. Description does not mention side effects, permissions, failure conditions (e.g., if not in an aircraft), or whether the data is real-time. For a read-only tool, basic safety assumptions are missing.

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

Conciseness4/5

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

Single sentence is efficient and front-loaded with the main verb and resource. No fluff, but could benefit from a slightly more structured format (e.g., bullet points for the listed fields).

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?

No output schema, so description partially compensates by listing return fields. However, it lacks details on data format, unit of measurement, or preconditions (e.g., player must be in an aircraft). Adequate for a simple tool but incomplete.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. Description adds value by enumerating the returned fields (position, altitude, etc.), which is beyond the schema.

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 retrieves specific information about the player's aircraft (position, altitude, speed, heading, fuel). It distinguishes from siblings like get_aircraft_list (lists all aircraft) and get_all_units (all units).

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?

No explicit when-to-use or alternatives are given. The description implies it's for the player's current aircraft, but does not differentiate from get_aircraft_list or get_mission_info for similar purposes.

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

get_theatre_infoA

Get information about the current theatre/map including terrain type and boundaries

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations exist, so the description must fully disclose behavioral traits. It only states 'Get information' which implies a read operation but does not explicitly confirm idempotency, side-effect freedom, or any authorization requirements. This minimal disclosure is insufficient for a tool with no structured annotations.

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 a single, front-loaded sentence that contains no superfluous words. It directly conveys the core purpose and two example outputs, making it highly efficient.

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 the tool's simplicity (no parameters, no output schema), the description covers the essential purpose and sample return fields. It is complete enough for an agent to understand what the tool does, though it does not mention possible additional return fields beyond 'terrain type and boundaries'.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the description does not need to add parameter meaning. The baseline score of 4 applies as no extra information is required or missing.

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 uses specific verb 'Get' and clearly identifies the resource as 'current theatre/map' with explicit outputs 'terrain type and boundaries'. It distinguishes itself from sibling tools like get_mission_info or get_aircraft_list which serve different purposes.

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

Usage Guidelines2/5

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, nor are there any exclusions or prerequisites. The description only implies usage for retrieving theatre information without helping the agent decide between this and other data retrieval tools.

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

send_messageB

Display a message to all players in the mission

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesMessage text to display
durationNoDuration to display message in seconds

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, and the description only says 'display a message', implying no side effects. However, it does not disclose whether permissions are needed, if the message overrides existing ones, or any other behavioral traits.

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?

Single sentence that is concise and front-loaded with the essential action and target.

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?

For a simple tool with two well-described parameters and no output schema, the description is mostly adequate. It could mention if the message is persistent or temporary, but the current level is sufficient given the context.

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% with clear parameter descriptions for 'text' and 'duration'. The tool description adds no additional meaning beyond 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 states the tool displays a message to all players, with a specific verb and resource. It is distinct from sibling tools like execute_lua or spawn_unit.

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

Usage Guidelines2/5

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, nor any exclusions or prerequisites. The description is a single statement without context.

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

spawn_unitA

Spawn a new unit in the mission at specified coordinates. Can use DCS coordinates (x, z) OR real-world coordinates (latitude/longitude or MGRS).

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesUnit type (e.g., 'M-1 Abrams', 'T-72B', 'F-16C_50')
nameYesName for the spawned unit
coalitionYesCoalition for the unit. Determines default country if 'country' is not specified.
countryNoSpecific country for the unit (overrides coalition default). Use CJTF_BLUE or CJTF_RED for combined joint task forces.
xNoDCS X coordinate (meters). Use this OR lat/lon/mgrs.
zNoDCS Z coordinate (meters). Use this OR lat/lon/mgrs.
latitudeNoLatitude in decimal degrees. Use with longitude instead of x/z.
longitudeNoLongitude in decimal degrees. Use with latitude instead of x/z.
mgrsNoMGRS coordinate string (e.g., '38TMK1234567890'). Use instead of x/z or lat/lon.
headingNoHeading in degrees (0-360)

TDQS

A3.7/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only states the action of spawning but does not disclose behavioral traits such as error handling, name uniqueness, permissions, or side effects. Minimal behavioral context.

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 with no waste. The first sentence states the main action, the second clarifies coordinate flexibility. Front-loaded and efficient.

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?

Given the tool complexity (10 params, no output schema), the description covers the core behavior but lacks details on return values, validation, or side effects. Adequate but not comprehensive.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by grouping coordinate options ('Can use DCS coordinates OR real-world coordinates'), clarifying the mutual exclusivity of parameter sets.

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 spawns a new unit at specified coordinates, using a specific verb and resource. It distinguishes between DCS and real-world coordinate systems, making the purpose unambiguous.

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?

Implied usage from the description, but no explicit guidance on when to use this tool vs alternatives like convert_coordinates. The description describes coordinate options but does not provide when-not or alternative tool references.

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. Dates show when Glama detected each change.

  1. 10 tool updatesv1.1.1
    • First observedconvert_coordinates
    • First observedconvert_dcs_to_ll
    • First observedexecute_lua
    • First observedget_aircraft_list
    • First observedget_all_units
    • First observedget_mission_info
    • First observedget_player_info
    • First observedget_theatre_info
    • First observedsend_message
    • First observedspawn_unit
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

All tools have clearly distinct purposes: coordinate conversion, Lua execution, various queries (aircraft, units, mission, player, theatre), sending messages, and spawning units. No overlapping functionality that would confuse an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, such as 'convert_coordinates', 'get_aircraft_list', 'send_message'. No mixing of conventions.

Tool Count5/5

10 tools are appropriate for the server's purpose of interacting with DCS. They cover essential operations without being excessive or too sparse.

Completeness4/5

The tool set covers major functionalities: coordinate conversion, querying units/aircraft/mission/player/theatre, sending messages, spawning units, and a generic Lua executor. Missing delete/modify operations for units or mission control, but the execute_lua tool can compensate, so only minor gaps.

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

  • CMO Agent Bridge

    Nuclear2
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to read and control Command: Modern Operations scenarios locally via MCP tools, supporting real-time battle assessment, task planning, and scenario editing.
    4
    MIT

  • DCS-ME-gateway

    ALasek
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI mission designers to author and validate DCS World missions through the Mission Editor via a versioned protocol, providing tools for planning, payloads, map inspection, and live editor integration.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sevenfifty777/dcs-lua-runner-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server