Connect your own agent

Two MCP servers run inside the desktop app. One exposes the Stage capability layer — the operations that describe a game rather than a file. The other exposes assets. An MCP-capable agent running on the same machine can call both.

This is a shipped feature rather than a plan, and there is a serving-contract test that keeps it honest, because a tool surface that quietly drifts is worse than no tool surface. What is not shipped, and never will be, is a bespoke integration with any particular agent product. We speak MCP. They speak MCP. That is the entire arrangement, and it is why we are not in the business of tracking anyone else's release schedule.

The practical caveat that follows: behaviour varies by client. Different agents handle tool discovery, errors, permissions and long-running calls differently, and we have not tested them all. Any client that speaks the protocol should be able to connect; how pleasant it is depends on the client.

The strongest reason is that you have a working setup and do not want a second one. If you already run an agent daily, know its habits, know when it is about to do something silly, and have your own model preference, that accumulated familiarity is worth keeping. Switching to a different agent for one part of your week has a real cost.

The second reason is scope. Sometimes the game is not the whole job. If your agent is already handling the repository, the build, the notes and the release, having it also reach into the engine keeps one thing in one place.

The third is control over the model itself, including running it on your own hardware. That works, with an important caveat covered on the local model pages: it does not make Stage Engine offline. Asset generation and world data still go over the network.

The world is still built by hand. Terrain, water, weather, buildings, characters and their placement are a person's work in the builder, and that is true no matter what is driving the code. There is no path where an agent quietly assembles a world for you, and there is not going to be one.

The project is still a real Godot project in a folder on your disk. Nothing about the agent path produces a different artefact, a proprietary format, or a project that only opens in one tool.

The game still runs locally when you press play, on the copy of Godot that ships inside the app. No streaming, no browser preview. And you still judge the result — play it, decide whether it is right, say what is wrong. That loop is the same whichever agent is on the other end of it.

Most of the time. Director 1 is aimed at the capability layer already, ships in the app, and has nothing to connect, configure or keep working when something upstream changes. If you do not have a strong existing attachment to another agent, this is simply the shorter route to a game.

It is also the better answer if the reason you are here is curiosity rather than a problem. Connecting an external agent adds a moving part. Moving parts are worth it when they solve something and a nuisance when they do not.

The two are not exclusive. Using Director 1 for the bulk of the work and your own agent for the parts where you want your own model is a normal way to work, and nothing in the app pushes you to pick.

External MCP access is part of the paid plans. Free is $0 a month, Indie is $10, Pro is $50. What the paid tiers buy is usage and this external access; the engine and the capabilities are the same on every plan.

Stage Engine is a desktop application for Mac and Windows. Godot ships inside it, so there is no separate engine install, and the agent connects locally on your machine rather than to anything of ours.

The connection details live in the app and its documentation, and deliberately not on this page. Config file contents and command names change; a stale snippet on a marketing page is worse than a pointer to the current one.