DEV Community: Fennara

I Tested Popular Godot MCPs by Migrating a Godot 3.6 Project to Godot 4.6

Fennara — Sun, 14 Jun 2026 03:48:43 +0000

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.

I used Fennara MCP to build a real Godot demo project

Fennara — Thu, 04 Jun 2026 05:06:04 +0000

I wanted to test something very specific:

Can an AI agent build inside Godot with real engine feedback, instead of just writing files and hoping they work?

So I made a small Godot demo project called Kantari using Fennara.

Video demo:

https://www.youtube.com/watch?v=8y2Ub8pgNSs

GitHub repo:

https://github.com/fennaraOfficial/kantari-godot-demo

Fennara:

https://www.fennara.io

The point of the demo

This is not meant to be a polished commercial game.

The point is to show a real saved Godot project created and iterated with Fennara: actual .tscn scenes, scripts, project settings, nodes, resources, and the Fennara addon payload.

Not a web scene.

Not a one-file runtime trick.

Not “one prompt makes a game.”

What Fennara is trying to solve

Most AI coding workflows can write Godot files from the outside.

That is useful, but it is also fragile.

The hard part is not only:

can the AI write a script?

The hard part is:

did the script parse?
did Godot understand the scene?
did the node paths work?
did resources load?
did the game produce runtime errors?
did the result actually look correct?

That is where Fennara is focused.

Small toolset, deeper feedback

Fennara MCP is not designed as a giant list of tiny Godot commands.

The philosophy is:

small toolset, deep Godot feedback

For example, when an AI agent writes or edits GDScript, Fennara can ask Godot for diagnostics on the changed script.

So the agent does not just get:

file written

It can get feedback from Godot about parse errors, type issues, warnings, or broken code it just introduced.

For scene work, Fennara can inspect Godot scene and node state, including changed properties, attached scripts, exported variables, subresources, nested resources, warnings, validation issues, runtime errors, and screenshots when visual feedback matters.

The goal is simple:

Give the agent enough Godot context that it does not have to hallucinate.

Why this matters for real projects

A lot of AI game-dev demos look impressive until you open the project.

The game might “run,” but the scene is fake, the code is brittle, node paths are wrong, resources are missing, or the whole thing only works because everything was hardcoded into one script.

Real Godot projects are messier than that.

They have:

scenes
inherited scenes
scripts
exported variables
signals
resources
subresources
autoloads
editor warnings
runtime errors
project-specific architecture

If the AI cannot inspect those things, it is mostly guessing.

Fennara tries to make the feedback loop tighter:

inspect project
edit
check diagnostics
validate scene
run
read errors
capture screenshot
patch
rerun

That loop is closer to how a human Godot developer works.

Kantari demo

Kantari is a small Godot demo project made with this workflow.

The repository includes:

a Godot project file
saved scene files
gameplay scripts
Fennara addon preview files
project setup files

GitHub:

https://github.com/fennaraOfficial/kantari-godot-demo

Video:

https://www.youtube.com/watch?v=8y2Ub8pgNSs

Fennara links

Website:

https://www.fennara.io

Godot MCP page:

https://www.fennara.io/godot-mcp

MCP setup docs:

https://www.fennara.io/docs/mcp

Closing thought

Fennara is not about making Godot optional.

It is about helping AI agents work inside Godot with enough feedback to notice when they are wrong.

The interesting part is not that the AI can make a change.

The interesting part is whether it can see what broke, understand why, and keep iterating.

I tested an AI agent on a real Godot RPG project. The first script broke.

Fennara — Fri, 29 May 2026 08:56:54 +0000

Most Godot AI demos start from an empty project.

I wanted to test a harder case: can an AI agent work inside an existing Godot project and recover when it makes a mistake?

So I tested Fennara MCP with Codex on GDQuest’s open-source Godot 4 Open RPG project.

The task was to add a progression feature where Baloo, the Bear player battler, unlocks a new combat ability called Tactical Guard after winning an encounter.

The interesting part: the first script Codex wrote was broken.

Instead of silently handing me broken Godot code, Fennara sent feedback from Godot back to the AI. Codex saw the diagnostics, patched the script, and kept going.

That is the part I care about.

Traditional MCP gives an AI commands.

Fennara gives the AI feedback from Godot:

GDScript diagnostics
scene validation
runtime feedback
scene tree inspection
node properties
SemanticSearch
patch-and-rerun workflows

The point is not that AI magically built a game.

The point is that AI agents need immediate feedback from the real engine before they can be trusted in real projects.

Video:

https://www.youtube.com/watch?v=0Egu3S-9MM0

Godot MCP overview:

https://www.fennara.io/godot-mcp