GDevelop MCP, what exists today and what an agent can do

A GDevelop project is JSON. By default it is one game.json file. In multiple files mode the scenes, external layouts, external events and extensions are split into their own files, and GDevelop recommends that mode for version control. GDevelop also warns that cloud sync tools such as Dropbox or OneDrive watching the folder can corrupt the project JSON.

Events are the hard part. In the official platformer example each condition and action is an object with a type such as `SystemInfo::HasTouchScreen` or `BuiltinExternalLayouts::CreateObjectsFromExternalLayout` and a list of positional string parameters, where text values carry their own escaped quotes. An agent editing that by hand has to get every identifier, parameter position and nesting level right, or the event loads but does not do what you meant. This is why the useful community servers validate edits against GDevelop's own sources or library instead of writing text. GDevelop also has JavaScript events, which an agent can write more reliably than raw event JSON.

Stay if you like building with events, if your team is not writing code, or if HTML5 publishing to many web destinations is the core of your release. GDevelop is built around that, while Summer web builds play on Summer Games. Stay too if the built-in agent's credits suit you. It knows every official extension and edits the project from inside the editor, which avoids the file format problem altogether.

Move when you want the agent to test, not only edit. Summer's agent runs the game, sends input, reads the player's position at the frame it lands, takes a screenshot and fixes what it finds. You write in GDScript, with C# available in the desktop editor, and you own the project with no royalties.

Summer does not import GDevelop projects. The rebuild reuses your art, audio and level design, and your event sheets become the specification for scripts. Summer builds desktop games for Windows and macOS for Steam and itch.io.