AI Game Dev
Home › Tutorials › The basics, part 5

How AI agents talk to your engine

An agent reaches a game engine three ways: it edits files, runs commands, or uses the editor through an MCP server. What works in Godot, Unity, Unreal and the web.

Interactive diagram of an AI agent reaching Unreal through three doors, Edit files, Command line and MCP server. The MCP route is lit, the agent sees the tool create node, and a small game scene shows the new enemy.

An AI coding agent such as Claude Code or Codex cannot click around in an editor the way you do. It reads files, runs commands and calls tools. So the useful question about any engine is: through which doors can the agent get in? There are three.

Try it below. Pick an engine and a task, then press a door. A message travels from the agent to the engine and back, and the panel shows what the agent can see on the way.

Try Unreal with "Add an enemy" through Edit files, then through the MCP server. The same job fails on a binary file and works through the editor.

Door 1: edit the project files

Every coding agent already has this door. It opens a file, changes it and saves it. This works as well as the engine’s files are readable text.

Godot is the best case. Scenes, resources and scripts are short text files. An agent can add an object to a scene by editing a few lines, and you can review the change.

Unity saves scenes and prefabs as text (YAML) only when a setting called Asset Serialization is set to “Force Text”. Check this setting first. The text is readable but long, and objects point at each other by ID numbers. Small edits are fine. Large scene changes by hand break easily. C# scripts are ordinary text.

Unreal is the hard case. C++ code is text, but Blueprints, levels, materials and most other assets are binary files. An agent cannot read or edit them directly. It needs one of the other two doors. In the demo above, this is the orange “Can’t do it” result.

Web stacks like Three.js and Phaser are all text: TypeScript, HTML, CSS and JSON.

Door 2: run the engine from the command line

An agent can run commands in a terminal. If the engine can build, run or test from a terminal, the agent can check its own work.

  • Godot runs a script with no window using --headless, and builds the game with --export-release. The option --quit-after stops after a set number of frames, which is handy for a short test run. Headless mode draws nothing, so for screenshots, run with a window and let the game save its own image.
  • Unity runs a C# method from the terminal with -batchmode and -executeMethod, and runs tests with -runTests. It often takes a minute or more to start, so the loop is slow.
  • Unreal uses UnrealEditor-Cmd and RunUAT to run, build and package. It works, but each step is heavy, and C++ compiles add more time.
  • Web games start with npm run dev, which reloads instantly. Playwright opens the page, presses keys, takes a screenshot and reads the console. This is the shortest loop of the four.

Door 3: MCP servers that use the editor

MCP (Model Context Protocol) lets an agent call tools that another program offers. An engine MCP server runs inside or next to the open editor. It offers tools such as “create node”, “set property”, “read console” and “take screenshot”. This fills the gap where files are binary or too awkward to edit.

This area changes every month. As of 2026-10-27:

  • Godot: no official server. Community servers exist, such as godot-mcp and godot-ai.
  • Unity: an official server in the AI Assistant package. It is in open beta, needs Unity 6 or later, a Unity Cloud connection and an AI subscription or trial. A popular community server, unity-mcp, also exists.
  • Unreal: an official MCP plugin in Unreal 5.8, still experimental. Community servers exist too.
  • Blender: an official server from Blender Lab, for Blender 5.1 and later.
  • Web: the browser is the editor. Microsoft’s Playwright MCP gives an agent the same open, click and screenshot tools.

Two warnings. These servers run code the model writes inside your editor, so keep the project in git and save a commit before each session. And more tools are not better. Some servers offer over a hundred tools, and every tool description uses up the agent’s limited memory for the conversation. Start with a small one.

The three doors side by side

Edit filesCommand lineMCP
GodotYesYesCommunity only
UnityPartly (with Force Text)Yes, slow startOfficial beta and community
UnrealPartly (C++ only)Yes, heavyOfficial is experimental
WebYesYesYes, through Playwright MCP

What to set up first

Before any MCP server, set up two things.

One command that builds and runs the game. For example npm run dev, or a small script that starts Godot with the right options. Write it in the project’s instruction file for the agent (CLAUDE.md or AGENTS.md). If the agent has to guess how to start the game, it guesses differently every session.

A way for the agent to see the result. A screenshot after a short run, or a log file with clear lines like “scene loaded: battle” and every error. Without this, the agent judges the game by its code. Code that looks right often plays wrong.

Once those two work, add an MCP server only for the jobs that files and commands cannot do.

That is the end of the basics. If you still need to choose an engine, go back to part 2.