Making games from Claude Code

We have not built anything specific to Claude Code. What we have built is a pair of MCP servers that ship inside the Stage Engine desktop app: one exposing the Stage capability layer, one exposing assets. Claude Code is an MCP client. Any MCP client should be able to reach those servers, and the popular ones are the ones people ask about.

That is the whole mechanism, and it is worth being precise about because the alternative framing is a lie. There is no extension, no marketplace listing, no plugin we maintain, and no partnership. Two pieces of software that both implement the same protocol can talk to each other. Behaviour will vary between clients, and we have not tested every one of them.

External access to those servers is part of the paid plans. Free is $0 a month, Indie is $10, Pro is $50. What the paid tiers buy is more usage and that outside access, not a different engine underneath.

If you already live in a terminal, the appeal is obvious: the agent you have tuned, with your prompts and your habits, pointed at a new domain. The problem is that a raw Godot project is a poor target for that. It is a directory of scenes, resources and scripts, and an agent working on it has to infer what a scene means, where a thing belongs, and how the world is put together. Inference is where the expensive mistakes live.

The capability layer is the difference. Instead of a pile of files, the agent gets operations at the level a game is described in: terrain of a given shape, water in a given outline, weather, sky, characters and what they do. Each of those is a body of code the model no longer has to write from nothing, and a class of failure that stops happening.

The practical consequence is that a cheaper, faster model composes reliably against a good layer, and you only need an expensive one for taste and for getting out of trouble. That is the thing worth having, and it is not something the protocol gives you on its own.

A game is not only code, and this is the honest limit of the whole approach. The world is built by hand, in the builder inside the app, by a person placing things and looking at them. That is not a restriction we imposed on external agents to protect the product. It is the design: taste lives in the world, and describing a hillside in a sentence is slower and worse than dragging one.

So the shape of the work is split. Your agent, in your terminal, handles the code and the operations the capability layer exposes. You handle the world, in the app, with your eyes on it. You also handle the judging. You play the game and say whether it is right, which is the part no agent does for you regardless of which one you picked.

If that split sounds like more app-switching than you want, it is a fair reason to use Director 1 instead and stay in one window.

Director 1 ships in the app. It writes GDScript into your project, and it already knows the layer, the project structure and the conventions, because it was built against them. There is nothing to connect and nothing to configure. For most people that is simply the faster path, and reaching for an external agent is effort spent on plumbing rather than on the game.

Bring your own agent when you have a real reason: an existing workflow you do not want to leave, a model choice you care about, or work that spans this project and others you already drive from the same place. Those are good reasons. Wanting to use the tool you like is also a good reason, and it is why the servers exist.

What you should not expect is a different quality of result because the agent is different. The capability layer is the same either way. That is the point of it.

Stage Engine is a desktop application for Mac and Windows, downloaded and installed, with its own copy of Godot inside it. There is no browser version and no cloud editor. The project it works on is a real Godot project in a folder on your machine, so your agent is operating on files that exist, and version control works the way you already expect.

When you press play, the game runs locally on the bundled Godot, using your machine. Nothing is streamed and nothing is rendered elsewhere.

Building does need an internet connection. The AI, asset generation and world data all come over the network, so this is not an offline tool no matter which agent is driving. Playing what you already built does not need the connection.

For the details of connecting a client, use the app and its documentation rather than a config snippet copied off a marketing page. Client setup differs between tools and changes between versions, and a stale example costs more than no example.