Game development over MCP

Two windows. Flockbay is open, showing your world and your game. Your agent is beside it, connected over MCP to the one server the app ships, which carries the capability layer, the assets and the game itself.

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.

More on this: Making games with local LLMs

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 Flockbay is described as a capability layer rather than an MCP wrapper around Godot. The protocol part took an afternoon. The layer is the product.

More on this: An AI agent that works inside a Godot project

The agent does not judge the world. It can call the world tools, and you can shape anything by hand with the builder in the Godot editor, but whether it looks and plays right is decided by a person playing it. If you were hoping to describe a world in a paragraph and never look at it, 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.

More on this: Making games from Cursor

Flockbay is a desktop application for 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.

Connecting your own agent over MCP is free. The platform itself is free. What Flockbay costs has the detail. The engine underneath is the same open-source Godot either way.

And if you have no particular attachment to an outside agent, Flockbay 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.

More on this: Making games from OpenCode