Game development over MCP

Two windows. Stage Engine is open, showing your world and your game. Your agent is beside it, connected over MCP to the two servers the app runs — one for the Stage capability layer, one for assets.

You spend most of the first hour in the app rather than the agent. Placing terrain, shaping where the water sits, deciding where the buildings go. This is the part that is faster with a mouse than with a sentence, and it stays a person's job on purpose.

Then the loop starts, and it is short. You ask the agent for behaviour. It writes GDScript into the project. You press play, the game runs locally on the bundled Godot, and you decide whether it is right. Usually it is not right the first time, which is not a failure state — it is the loop working. You say what is wrong and go again.

Plenty of people have pointed a capable agent at a game project and been disappointed. The failure is rarely stupidity. It is that a game project does not describe itself. The meaning is spread across scenes, resources, node names and conventions nobody wrote down, so the agent reconstructs it from scratch on every turn and is subtly wrong in a different way each time.

Give it file-level tools and the problem gets worse rather than better. "Set property on node" is a keystroke, not an operation. An agent can execute a hundred of them correctly and still not have made anything, because none of them are at the level a game is described in.

So the useful work in MCP game development is not the plumbing. It is deciding what the operations should be. That is a design problem about games.

A capability earns its place when it collapses something the model would otherwise invent. Terrain of a given shape. Water that behaves like water. Weather, sky, characters and what they do. Each of those, once it is a real operation, is a body of code the agent never writes and a family of bugs that stops appearing.

The commercial consequence is the one worth understanding. When the layer is good, a modest model composes against it reliably, and you only need an expensive one for taste and for recovering from something odd. Reliability that comes from the tools rather than from model size is cheaper and steadier than the alternative.

That is why Stage Engine is described as a capability layer rather than an MCP wrapper around Godot. The protocol part took an afternoon. The layer is the product.

The agent does not build the world. That is a person, by hand, in the builder, and it is not a gap that gets filled in a later release. If you were hoping to describe a world in a paragraph and have it appear, this workflow will disappoint you.

Building needs an internet connection. Asset generation and world data come over the network, and that stays true whatever agent or model you are using and wherever it runs. Playing the finished game does not need a connection.

We have no bespoke integration with any agent product. No plugin, no extension, no listing. Any client that speaks MCP should be able to connect, we have not tested every one, and behaviour varies. The connection details live in the app and its docs rather than on this page, because published configuration goes stale and a wrong instruction is expensive.

Stage Engine is a desktop application for Mac and Windows. Godot ships inside it, so there is nothing else to install, and your project is a real Godot project in a folder on your disk rather than a file only this tool can open.

External MCP access is on the paid plans. Free is $0, Indie is $10 a month, Pro is $50. Those buy usage and this access, not a different engine.

And if you have no particular attachment to an outside agent, Director 1 ships in the app, is already aimed at the capability layer, and requires none of this. It is the shorter path and there is no penalty for taking it.