I tested three Godot MCPs by giving Codex the same task:
Connect to a Godot 3.6 project and migrate it to Godot 4.6.
Simple test.
Same project. Same prompt. Different MCPs.
One of them was my own MCP, Fennara. The other two were Godot AI and Godot MCP Native.
The project started with:
- 208 errors
- 73 warnings
So this was not a clean small demo. It was a real messy migration test.
Test 1: Fennara
Fennara started by checking if Codex was connected to the correct Godot project.
Then Codex ran diagnostics across the project.
This is where Fennara helped a lot.
It did not just read the editor output panel. It surfaced:
- script errors
- scene errors
- shader errors
- old Godot API errors
- errors that were not clearly shown in the editor
Codex also used Fennara's get_class_info tool many times.
That matters because Godot 3 to Godot 4 migration has a lot of API changes.
If the AI guesses the new API, it can easily write wrong code.
But if the AI can ask Godot directly, the edits become much safer.
When Codex edited files through Fennara, the write result immediately returned the new errors and warnings for that script.
So Codex was not just writing code and hoping it worked.
It was getting feedback from Godot after the edit.
That is the whole point.
AI agents should not build blindly.
Yes, Fennara's write tools are slower.
But they are slower because they are more careful.
Every action reflected in the editor instantly. I did not get the same editor caching problem that showed up in the other MCPs.
After another diagnostics run, the errors went down a lot.
Fennara also helped catch runtime errors. One example was old code calling add_animation on AnimationPlayer.
By the end, Codex reached a much better state on its own. I did not manually guide it through the fixes.
Test 2: Godot AI
Next I tested Godot AI.
I gave Codex the same migration prompt again.
It started by running the project.
The problem was that the tool only said the project was running. It did not clearly return the runtime error, even though the scene was broken.
Then Codex started reading game and editor logs.
And this is where things became messy.
The editor logs had old errors inside them.
Some errors were from before the files were changed. Some were not true anymore.
Codex noticed this too.
It basically said the logs still had errors for lines that were not even on disk now.
That is a big problem.
Because if the AI trusts stale logs, it starts fixing errors that do not exist anymore.
Later Codex decided to use the Godot executable directly from the terminal because the terminal output was cleaner.
That helped, but then the MCP was not really giving the clean feedback loop.
At one point Codex thought the migration was finished.
But after reloading the project, there were still around 30 errors left.
So I had to run the scene and provide screenshots a few times to help it continue.
Test 3: Godot MCP Native
Then I tested Godot MCP Native.
This one had similar issues.
At first Codex could not find all the tools properly, so I gave it the repo README.
After that, it understood the tools better.
But this also showed one downside of having too many tools.
The agent may not know what to use.
During the migration, Codex still relied a lot on running Godot directly from terminal instead of using the MCP.
And yes, Codex can still fix things that way.
But the test was not only about whether Codex can eventually fix the project.
The test was:
How much does the MCP help Codex understand the Godot project state?
After Codex thought it was finished, I reloaded the project.
There were still errors left.
The Main Difference
The biggest difference was the feedback.
For Godot migration work, AI needs more than file access.
It needs reliable feedback from Godot.
The biggest problems I saw were:
- stale editor output
- runtime errors not being returned clearly
- editor cache issues after file writes
- agents fixing errors that were already gone
- too many tools making discovery harder
- not enough direct Godot API context
This is why I built Fennara around fewer tools, but deeper feedback.
Instead of being just a big command list, Fennara tries to give the agent useful Godot context:
- project diagnostics
- script diagnostics after edits
- scene and node inspection
- changed properties
- exported script variables
- attached script info
- validation warnings
- runtime errors
- class and method information from Godot
That feedback loop is what helped Codex avoid guessing.
Final Thoughts
Yes, this video is partly me praising my own MCP.
I know.
But everything I showed in the test was raw and real.
The main thing I believe is this:
The more reliable feedback an MCP gives the agent, the less the agent has to hallucinate.
For Godot projects, especially migrations, that matters a lot.
Try different MCPs and see what works for your own workflow.
Some tools may fit your style better than others.
But for me, the best MCP is not the one with the biggest command list.
It is the one that helps the AI understand what Godot is actually saying.