Skip to main content
Glama
rochana-sadila

defold-mcp

defold-mcp

An MCP server that gives AI coding agents full control over Defold game engine projects — inspect, scaffold, edit, build, run, and test.

License Node TypeScript MCP

An MCP (Model Context Protocol) server that gives AI coding agents — Claude Code, OpenCode, and Codex — full control over a Defold game engine project. It lets an agent inspect a project, scaffold brand-new projects, write scripts, edit collections, build with bob.jar, run the game headlessly, and run a Lua test suite — all over a local stdio connection.

defold-mcp is a Node.js / TypeScript ESM server. It is a local development tool: it talks to your Defold project on disk and shells out (only) to java -jar bob.jar and dmengine_headless. There is no HTTP/SSE transport and no authentication — it is intended strictly for local use.

Table of Contents

Related MCP server: Godot MCP

🎮 Overview

An MCP (Model Context Protocol) server that gives AI coding agents — Claude Code, OpenCode, and Codex — full control over a Defold game engine project. It lets an agent inspect a project, scaffold brand-new projects, write scripts, edit collections, build with bob.jar, run the game headlessly, and run a Lua test suite — all over a local stdio connection.

defold-mcp is a Node.js / TypeScript ESM server. It is a local development tool: it talks to your Defold project on disk and shells out (only) to java -jar bob.jar and dmengine_headless. There is no HTTP/SSE transport and no authentication — it is intended strictly for local use.

✨ Features

A quick glance at the 10 tools the server exposes:

  • Inspect project config & file tree

  • Read / write scripts and files

  • Scaffold new Defold projects

  • Edit collections (objects/components/props)

  • Build with bob.jar

  • Run the game headlessly

  • Run a Lua test suite

  • Hot reload (experimental)

📦 Install / Build

Requirements:

  • Node.js 20+

  • A Defold project (a directory containing game.project), or let the server scaffold one with defold_init_project.

  • bob.jar and dmengine_headless must be provided by you (see below). They are not bundled.

npm install      # install dependencies
npm run build    # compile TypeScript -> dist/ (runs tsc)
npm start        # run the stdio MCP server (node dist/index.js)

For development without a build step:

npm run dev      # run directly from source (tsx src/index.ts)

npm start is what MCP clients launch. It runs node dist/index.js, which is the built stdio server entrypoint.

⚙️ Environment Variables

The server is configured entirely through environment variables. DEFOLD_PROJECT_PATH is the only commonly required one; the build/run tools degrade gracefully to clear errors if BOB / DMENGINE_HEADLESS are absent.

Variable

Required?

Default

Description

DEFOLD_PROJECT_PATH

Recommended

process.cwd()

Absolute path to your Defold project root — the directory that contains game.project. All file operations (read, write, init) and project inspection are scoped to this directory. Every tool that touches the filesystem validates the target against this root (path-traversal protected). If omitted, the server falls back to process.cwd() (the directory it is launched from). Must exist.

BOB

Optional

<DEFOLD_PROJECT_PATH>/.defold/bob.jar

Absolute path to bob.jar — the official Defold build tool. If omitted, the server looks for <DEFOLD_PROJECT_PATH>/.defold/bob.jar. Download it from the Defold releases page — pick a release, open the bob asset, and grab bob.jar. The server never auto-downloads it.

DMENGINE_HEADLESS

Optional

PATH lookup

Absolute path to the dmengine_headless binary — the headless Defold engine used to run the game and tests. If omitted, the server performs a PATH lookup for dmengine_headless.

DEFOLD_PROJECT_PATH=/home/you/projects/my-defold-game
BOB=/opt/defold/bob/bob.jar
DMENGINE_HEADLESS=/opt/defold/bin/x86_64-linux/dmengine_headless

🔌 MCP Client Registration

Register defold-mcp with your MCP client as a stdio server. The command launches node with the built entrypoint dist/index.js as its single argument. Replace the placeholder paths with real absolute paths on your machine.

Add to your project's .mcp.json (or configure globally via claude mcp add):

{
  "mcpServers": {
    "defold": {
      "command": "node",
      "args": ["/abs/path/to/defold-mcp/dist/index.js"],
      "env": {
        "DEFOLD_PROJECT_PATH": "/abs/path/to/your-defold-project",
        "BOB": "/abs/path/to/bob.jar",
        "DMENGINE_HEADLESS": "/abs/path/to/dmengine_headless"
      }
    }
  }
}

Add to ~/.config/opencode/opencode.json (or a project-local .opencode.json):

{
  "mcpServers": {
    "defold": {
      "command": "node",
      "args": ["/abs/path/to/defold-mcp/dist/index.js"],
      "env": {
        "DEFOLD_PROJECT_PATH": "/abs/path/to/your-defold-project",
        "BOB": "/abs/path/to/bob.jar",
        "DMENGINE_HEADLESS": "/abs/path/to/dmengine_headless"
      }
    }
  }
}

Add to ~/.codex/config.toml (or a project-local codex.config.toml):

[[mcp_servers]]
name = "defold"
command = "node"
args = ["/abs/path/to/defold-mcp/dist/index.js"]

[mcp_servers.env]
DEFOLD_PROJECT_PATH = "/abs/path/to/your-defold-project"
BOB = "/abs/path/to/bob.jar"
DMENGINE_HEADLESS = "/abs/path/to/dmengine_headless"

🛠️ Tools Reference

Tool

Input

Description

defold_project_info

{}

Parse game.project, return {title, resolution:{width,height}, mainCollection, dependencies[]}.

defold_list_project

{path?: string}

Recursively list .collection/.go/.script/.atlas/.tilesource files, skipping build/ and .internal/. Returns an indented tree.

defold_read_file

{path: string}

Read raw file text (path-traversal protected).

defold_write_script

{path: string, content: string}

Write/overwrite a .script Lua file (creates parent dirs). Path must end in .script.

defold_init_project

{name: string, targetPath?: string}

Scaffold a new project (game.project, main collection, script, .gitignore). Refuses to overwrite an existing one.

defold_edit_collection

{collectionPath, operation, params}

Add a game object, add a component, or set a property on a .collection; returns a unified diff.

defold_build

{variant?, archive?}

Run java -jar bob.jar resolve build (120s timeout), return {success, errors, rawLog} with parsed errors.

defold_run_headless

{timeoutSec?, settingsFile?}

Run the built engine headlessly, capture logs, kill after timeout (no zombies).

defold_run_tests

{testFile?}

Build with --variant headless, run headlessly, parse PASS:/FAIL: lines into pass/fail results.

defold_hot_reload

{}

EXPERIMENTAL best-effort engine hot reload. Always returns a structured result; never crashes the server.

✅ Test Script Convention

Test scripts are ordinary Defold Lua scripts (.script / .lua) that run under the headless engine. To report results, print lines in one of these two exact formats:

PASS: <test_name>
FAIL: <test_name>: <reason>

Examples:

print("PASS: player_spawns_at_origin")
print("FAIL: inventory_adds_item: expected 1 item, got 0")

defold_run_tests collects every PASS:/FAIL: line from the engine log and returns {passed, failed, details:[{name, status, message?}]}. Any line that does not match the convention is ignored. If the build step fails, tests are not run and buildErrors is returned in the result.

⚠️ Known Limitations

  • Collection parser is a custom brace-delimited implementation, not a full protobuf schema. It parses and serializes the Defold protobuf-text .collection / .go format (key { ... } blocks and key: value scalars) and is verified by round-tripping real-format samples. It is not a complete protobuf round-trip; re-build and visually verify after any collection edit.

  • Hot reload is experimental. The Defold engine service protocol is version-dependent and undocumented; it will likely fail on many setups. The tool always falls back to a clear structured message — use defold_build + relaunch instead.

  • bob.jar and dmengine_headless are not bundled. The server requires you to provide them (see Environment variables). If missing, the build/run/test tools return clear errors instead of crashing.

  • Stdio only. No HTTP/SSE transport. No authentication — intended strictly as a local development tool.

🗺️ Roadmap

All planned v1 tools are implemented.

🤝 Contributing

Issues and pull requests are welcome. If you'd like to contribute, open an issue to discuss the change first for anything substantial. By contributing you agree your contributions are licensed under the terms of the MIT License.

📄 License

defold-mcp is released under the MIT License. See the LICENSE file for the full text.

Available Tools

1 tool
defold_project_infoA

Read and summarize the game.project file (title, resolution, main collection, dependencies).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

The description explicitly states 'Read and summarize,' indicating a read-only, non-destructive behavior. No annotations are provided, but the description itself sufficiently discloses the tool's behavior. No additional behavioral traits (e.g., side effects) are necessary given the simplicity.

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, well-structured sentence that front-loads the action and lists key outputs. Every word adds value; no unnecessary content.

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?

Given the tool has no parameters, no output schema, and no siblings, the description fully covers the necessary context. It explains what the tool reads and what information it summarizes, which is sufficient for an agent to decide to use it.

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, so the schema coverage is 100% trivially. The description adds no parameter information, but baseline 4 is appropriate for 0 parameters as per criteria.

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 reads and summarizes the game.project file, listing specific fields (title, resolution, main collection, dependencies). It uses a specific verb ('Read and summarize') and identifies the exact resource, 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 Guidelines4/5

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

While no explicit when-to-use or alternatives are given, the description implies it is appropriate when needing a summary of the game.project file. The lack of sibling tools reduces the need for differentiation, and the context is clear enough for an agent to infer usage.

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. 1 tool updatev0.1.0
    • First observeddefold_project_info

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools.

Naming Consistency5/5

A single tool inherently has no naming conflicts or inconsistencies.

Tool Count2/5

A single tool for a game engine server is too limited; typical servers have more tools for broader functionality.

Completeness1/5

The server only provides a read-only summary of a project file, lacking essential operations like project creation, asset management, or build commands.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    Not graded
    maintenance
    Enables AI agents to fully control the Forge Engine (Godot fork) by manipulating scene trees, modifying node properties, and managing game scripts. It allows agents to perform development tasks such as running projects, capturing screenshots, and executing GDScript through a WebSocket connection.
    21
    -
  • A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to create, edit, and run Godot 4.5+ games by providing tools for project scaffolding, scene manipulation, and engine interaction. It supports full game development workflows including node editing, script attachment, and project execution with debugging capabilities.
    24
    5
    MIT
  • A
    license
    C
    quality
    A
    maintenance
    Enables AI agents to interact with the Godot game engine, including project inspection, scene/script parsing, headless exports, runtime control with live scene-tree inspection and evaluation, and API documentation search.
    100
    379 npm
    2
    MIT