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:
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:
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.
Top comments (0)