Working with Godot MCP and OpenRouter: Why I Landed on Luna

I have been planning a small Godot game. The plan was the easy part. The next question was practical. Could an AI assistant work with the project itself? Not just explain GDScript in a chat window. Could it see enough of the project to help me inspect scenes, understand scripts, and make useful changes?

That question sent me down the MCP rabbit hole. I got a Godot MCP server working. I connected it through OpenRouter. I tried several models. Some looked impressive in isolation. They were less useful once they had to work inside a real project.

I eventually landed on Luna. It was not a dramatic one-click win. It was the result of testing, adjusting, and noticing which model helped instead of merely talking.

The problem with a chat window

A normal AI chat starts with very little context. I can paste a script. I can describe a scene. I can attach an error. Then I wait for an answer. That works for small questions. It gets awkward quickly.

A Godot project has relationships. Nodes belong to scenes. Scenes reference scripts. Scripts expect signals. Resources point at other resources. A short code sample rarely tells the whole story.

The assistant needs project context. It needs to know what exists before it suggests something new. Otherwise it invents paths. It guesses node names. It rewrites a function that was already fine.

That is the promise of MCP, the Model Context Protocol. An MCP server gives a model a defined way to interact with tools and context. The model does not magically understand the project. The server exposes useful operations. The client decides which operations are available. The model can then use those tools when they are appropriate.

That distinction matters. MCP is not a replacement for Godot. It is a bridge between the assistant and the editor or project workflow.

Getting the pieces to talk

There were four moving parts:

• Godot — the game project and the place where changes matter.
• The MCP server — the bridge exposing Godot-aware actions and information.
• The MCP client — the tool that connects the assistant to the server.
• OpenRouter — the model gateway that let me try different models without rebuilding the whole setup each time.

The rough shape looks like this:

Godot project
    ↓
Godot MCP server
    ↓
MCP client
    ↓
OpenRouter
    ↓
Selected model

The arrows are simple. The setup was not always simple. A connection can be alive while the useful part is broken. The model can respond while having no helpful project context. A tool can be visible but poorly described. Every layer can look healthy on its own while the full workflow fails.

I learned to test the whole chain. A successful connection message was only the beginning.

The first useful test

I did not start by asking the assistant to build a game. That would mix too many problems together. I started with a small, verifiable task:

Inspect the current Godot project. Tell me which main scenes and scripts exist.
Do not create or change anything yet.

That prompt gave me a baseline. Could the model see the project? Could it distinguish a scene from a script? Could it report what was actually there instead of filling in a familiar-looking answer?

The second test was equally small:

Find the player script. Explain its current movement flow in a short list.
Do not rewrite it.

The restriction was important. I wanted observation before action. A model that can explain the existing code is safer than one that immediately replaces it.

Trying different models through OpenRouter

OpenRouter made the comparison practical. I could keep the Godot and MCP side mostly stable while changing the model behind the connection. That turned model choice into a workflow question instead of a branding question.

I tried several models. They differed in ways that mattered more than a benchmark score:

• Context discipline — did the model use the project information it had?
• Tool discipline — did it call a tool when it needed one, or guess instead?
• Change size — did it suggest a small patch or rewrite half the project?
• Godot fluency — did it understand nodes, scenes, signals, resources, and GDScript?
• Conversation memory — could it keep a decision in mind across several steps?
• Error recovery — did it read the error and adjust, or repeat the same answer?

Some models were excellent at explaining a concept. Some produced polished GDScript. Some were fast. None of those traits guaranteed a good Godot workflow.

The real test was a boring task. Make one small change. Check the result in Godot. Report the error if there is one. Ask for the next change. A model that stayed close to that loop was more valuable than one that delivered a brilliant but oversized first answer.

Why Luna won for me

I eventually settled on Luna. That does not mean Luna is the best model for every Godot project. It means Luna produced the best balance for this one and for the way I work.

It stayed closer to the requested scope. It was willing to inspect before changing. Its suggestions were easier to review. When something failed, the next response was more likely to address the actual failure instead of starting over with a new architecture.

That last point changed the experience. Game development is full of partial problems. A node is in the wrong place. A signal has the wrong name. A typed value is not the type the script expected. The answer does not need to be grand. It needs to be accurate enough for the next test.

A better working loop

The connection became useful once I stopped treating the model like a code generator. My loop now looks more like pair debugging:

1. State the goal — one feature or one bug.
2. Ask for inspection — identify the relevant scene, node, and script.
3. Confirm the plan — ask what will change and what will stay untouched.
4. Make the smallest edit — one script, one scene, or one resource.
5. Run Godot — let the engine be the source of truth.
6. Report the actual result — include the error, not my guess about it.
7. Repeat — only expand the task after the small version works.

That loop sounds slower than asking for a complete system. It is faster than debugging a complete system I do not understand.

The process also gives me a record of decisions. Why is the player movement in this script? Why does the scene own this signal? Why is this resource data-driven? The assistant can help surface those questions, but I still make the decisions.

What MCP does not solve

MCP gives the model a better way to work with context. It does not make the model correct. It does not make a bad project structure good. It does not replace running the game.

There are still limits:

• A tool may expose the wrong level of detail.
• A model may misunderstand a valid but unusual design.
• A generated change can still introduce a subtle bug.
• The editor can reveal a problem that the model cannot predict.
• Credentials and tool permissions still need care.

I treat every tool call as a suggestion with consequences. The more destructive the action, the more review it gets. Reading a scene is low risk. Rewriting a project-wide script is not.

The safest setup is not the one that gives the model unlimited control. It is the one that makes the useful actions easy and the dangerous actions deliberate.

The connection to the game plan

This experiment fits the small-game plan I wrote about in Planning a Godot Game. The first milestone is still a gray-box level. The MCP workflow does not change that scope. It should make the small steps easier to take.

I can ask the assistant to inspect the player scene. I can ask it to explain a movement error. I can ask for a focused change. Then I can run the game and decide whether the change belongs in the project.

That is the useful boundary. Luna can help me move through the work. It does not get to decide what game I am making.

The setup is working. The remaining percentage is not a technical score. It represents the part I only get by using the workflow on real features. A connection is not a finished process. The process has to survive contact with the game.

What I would do differently

I would start with a smaller test. My first instinct was to ask for too much context and too many actions at once. That made it hard to tell whether a problem came from Godot, MCP, OpenRouter, the model, or my prompt.

I would also keep a model comparison note from the beginning. Short entries would have been enough:

Model:
Task:
Used the available context: yes/no
Made a focused suggestion: yes/no
Needed correction: yes/no
Would I use it again for Godot: yes/no

That is more useful than trying to remember which model felt good after a long evening of configuration.

Finally, I would define permissions before testing. Read-only inspection is a good first mode. Write actions can come later. The project is still mine. The assistant should earn access by being useful and predictable.

What comes next

The next test is the one that matters: use this workflow to finish the first gray-box milestone. A player. A camera. One level. One clear exit.

After that, I want to try a few focused tasks. A checkpoint system. A small HUD. A clean restart flow. Each task should teach me something about both Godot and the MCP setup.

I am not trying to outsource game development. I am trying to remove some of the friction between an idea and a playable test. OpenRouter made model comparison accessible. MCP gave the assistant a way into the project. Luna is the model I currently trust in that loop.

The important part is the loop itself. Inspect. Plan. Change one thing. Run the game. Learn. Repeat.

That is how this Godot project starts becoming a game instead of another idea waiting in a notes folder.