defold-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@defold-mcpInspect my Defold project's file tree"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
defold-mcp
An MCP server that gives AI coding agents full control over Defold game engine projects — inspect, scaffold, edit, build, run, and test.
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.jarRun 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 withdefold_init_project.bob.jaranddmengine_headlessmust 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 |
| Recommended |
| Absolute path to your Defold project root — the directory that contains |
| Optional |
| Absolute path to |
| Optional |
| Absolute path to the |
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 |
|
| Parse |
|
| Recursively list |
|
| Read raw file text (path-traversal protected). |
|
| Write/overwrite a |
|
| Scaffold a new project (game.project, main collection, script, .gitignore). Refuses to overwrite an existing one. |
|
| Add a game object, add a component, or set a property on a |
|
| Run |
|
| Run the built engine headlessly, capture logs, kill after timeout (no zombies). |
|
| Build with |
|
| 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/.goformat (key { ... }blocks andkey: valuescalars) 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.jaranddmengine_headlessare 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 tooldefold_project_infoA
Read and summarize the game.project file (title, resolution, main collection, dependencies).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
defold_project_info
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools.
A single tool inherently has no naming conflicts or inconsistencies.
A single tool for a game engine server is too limited; typical servers have more tools for broader functionality.
The server only provides a read-only summary of a project file, lacking essential operations like project creation, asset management, or build commands.
Maintenance
Related MCP Connectors
- ApricotOAuthtools.apricot
Manage SysML2 projects and files directly through your coding agent.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Build and deploy websites, Telegram and Discord bots from chat via the DreamAgent platform.
Related MCP Servers
- AlicenseAqualityNot gradedmaintenanceEnables 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-
- AlicenseAqualityDmaintenanceEnables 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.245MIT
- AlicenseAqualityDmaintenanceEnables AI agents to launch, edit, debug, and test Godot game projects with comprehensive scene and script manipulation tools.501MIT
- AlicenseCqualityAmaintenanceEnables 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.100379 npm2MIT