Godot Reusable Game Kit Integration: The Full Review-and-Deliver Workflow

Delivering a reusable gameplay kit into a Godot project follows a discover → manifest → dependency check → dry run → deliver → verify workflow, with rollback available if needed. Start by confirming whether an action writes into your actual local Godot folder or just updates state inside a GripForge project on the server. Godot delivery provides scenes, scripts and resources. Unity and Unreal delivery depends on the kit: many paths provide integration recipes, while modules such as combat.abilities can provide source files. Inspect the actual delivery result for the selected module and target. Local application of a Godot bundle requires a separate local tool or import step. Before any of that, always review the add/keep/modify/delete/conflict plan and let the tool create backups — don't force an overwrite over files you've already hand-edited.

This matters because integration involves more than copying a downloaded bundle into res://. It's a manifest-described package with declared provides/requires, config slots, data collections and events, resolved through MCP tools before anything touches disk.

Step 1 — Discover kits that match your target

Use gripforge_gamekit_search with a query, capability, tag, or target filter (e.g., godot) to list candidates. A kit showing up in the catalogue for a target is not a guarantee that every capability in it is actually implemented for that target — treat search results as leads, not commitments.

Acceptance criteria: you have a short list of kit IDs whose declared target includes godot, not just "engine-agnostic."

Step 2 — Pull the full manifest before deciding anything

Run gripforge_gamekit_get on each candidate. Read provides/requires, slots, data collections, events, the README, and the config schema with its defaults. This is where you catch a kit that requires a system (say, an inventory event bus) your project doesn't have yet.

Acceptance criteria: you can state, in one sentence, what the kit adds and what it assumes already exists in your project.

Step 3 — Check dependencies and conflicts

Call gripforge_gamekit_dependencies to surface conflicts and unresolved requirements against what's already installed. If you're layering a second kit (say a dialogue kit on top of an inventory kit), this is the step that tells you if their provides/requires graphs actually line up.

If the kit exposes configuration, apply your intended values with gripforge_gamekit_configure, which validates the schema and updates stored configuration when successful. This is a state-changing step, not a read-only validator.

Acceptance criteria: zero unresolved requirements, and any reported conflicts are ones you understand and accept.

Step 4 — Dry-run before you write anything

gripforge_gamekit_install resolves manifest dependencies and, with dry_run set, returns a plan without writing anything. gripforge_gamekit_deliver also accepts dry_run, plus target, kits or project_id, mode, and project_state. Run the dry run and actually read the plan's per-file actions: add, keep, modify, delete, conflict.

conflict entries are the ones to slow down for — they usually mean a file the kit wants to touch has diverged from what it expects (often because you edited it). Never treat a dry-run pass as a green light to blanket-overwrite; review each conflict individually.

Acceptance criteria: you've read every conflict and delete entry and decided, file by file, whether it's acceptable.

Step 5 — Server install vs. local delivery: pick the right one

Keep server-side kit state separate from files in your local working copy:

• Server-side install (gripforge_gamekit_install) resolves dependencies and records the kit in a GripForge project. Hosted delivery (gripforge_gamekit_deliver) prepares the supported bundle or recipe from selected kits or a project. Neither operation directly writes into your local Godot folder.
• Local delivery into your actual Godot working copy requires the local MCP client, the npm package @gripforgeai/mcp. Its gripforge_gamekit_deliver_local tool takes a project_dir pointing at your real Godot project and executes the reviewed plan there, creating backups as it goes.

If you only ran hosted delivery, it has not installed the files into your local project. Apply the result through local delivery or an explicit import workflow, then test the integration.

Step 6 — Deliver into the Godot project, then verify

With the local client, run gripforge_gamekit_deliver_local against project_dir. For a supported Godot kit, inspect the delivered scene, script and resource files. Other targets can receive recipes or source files depending on the module; this guide covers the Godot file-delivery path. Review the current actions against your current files, since they may have changed after an earlier dry run. The tool applies delivery with backups and uses GODOT_BIN for verification — set this environment variable to your Godot executable path so the local client can open/check the project after writing.

Acceptance criteria: delivery reports success, GODOT_BIN verification passes, and the project still opens cleanly in the editor with no missing-script or broken-resource errors.

Step 7 — Rollback if something's wrong

If verification fails or the kit behaves badly in-editor, run gripforge_gamekit_rollback_local with the same project_dir to undo the delivery using the backups created during Step 6. Rollback restores what delivery touched — it isn't a substitute for version control, so commit before you deliver.

Conflict and backup checklist

Troubleshooting

• "Kit found in search but nothing happens in Godot." You likely ran the hosted gripforge_gamekit_deliver only. Repeat delivery through the local client with project_dir set.
• Unresolved dependency after install. Re-run gripforge_gamekit_dependencies — you may need a second kit installed first, or a config value set via gripforge_gamekit_configure.
• Verification fails but files look fine. Confirm GODOT_BIN points to a valid Godot executable for your project's engine version; also inspect the reported parse, import or runtime errors; a valid binary path does not rule out an integration problem.
• Conflicts on every delivery. You've likely hand-edited files the kit manages. Move your custom logic to a separate script/scene that calls into the kit's exposed events instead of editing kit files directly.

FAQ

Does dry-run ever write files?

With dry_run set, these operations provide a plan without applying the installation or delivery changes. Server installation and local file delivery remain separate state-changing steps when you run them for real.

Can the hosted MCP endpoint update my local Godot files directly?

No. The hosted endpoint returns asset URLs or a delivery bundle; use the local @gripforgeai/mcp delivery client with project_dir, or another explicit local import workflow, to apply those files.

What does rollback actually restore?

Whatever gripforge_gamekit_deliver_local backed up during its run for that project_dir. It's not a general version-control replacement, so commit your project before delivering.

For the underlying tool list and current argument details, check the MCP docs and the general GripForge docs. If you're assembling a level around a delivered kit, see From Level Plan to Playable Greybox with GripForge, and for broader MCP setup in your coding agent, see MCP for game development with Claude Code and Cursor.