Summer Engine MCP Prompt Templates for AI Game Development

Most AI game prompts are too vague. They ask for a whole game, then leave the agent guessing about the scene tree, scripts, assets, and errors.

Summer Engine MCP works better when the prompt asks for a tight loop:

1. Inspect the project.
2. Make one playable change.
3. Save the scene.
4. Run the game.
5. Read errors.
6. Fix what broke.
7. Report the tool trace.

That loop matters because game state does not live only in code files. It lives in scenes, nodes, resources, imports, project settings, and the running editor. Summer's MCP server gives agents a documented tool surface to work with that state directly.

Use these prompts as starting templates in Claude Code, Cursor, Codex, Gemini CLI, Windsurf, Cline, Roo Code, OpenCode, or any other MCP client connected to Summer Engine.

The desktop app is free to download and use, but its source code is not public right now. The AI-agent layer, meaning the CLI, MCP server, skills, hooks, and plugin manifests, is MIT open source. Hosted Summer AI, asset generation, storage, multiplayer, orchestration, and cloud features are paid Summer services.

Prompt Template 1: First Playable 3D Prototype

Use Summer Engine MCP to make a tiny playable 3D prototype.

Goal: a player can move around a simple arena, collect 5 pickups, and see a score.

Before changing anything:
- Call the project-context and scene-tree tools.
- Tell me what scene is currently open.

Then:
- Build the smallest playable version.
- Save the scene.
- Run the game.
- Read script and runtime errors.
- Fix any errors you caused.

End with a short trace: tools called, files/scenes changed, what I can test.

Expected trace shape:

summer_get_project_context
summer_get_agent_playbook
summer_get_scene_tree
summer_add_node / summer_set_prop / summer_connect_signal
summer_save_scene
summer_get_script_errors
summer_play
summer_get_debugger_errors

Done means the game enters Play mode and the user can verify movement plus pickup collection.

Prompt Template 2: Add a Mechanic to an Existing Scene

Use Summer Engine MCP to add one new mechanic to the current scene.

Mechanic: dash on Shift with a short cooldown and a visual trail.

Rules:
- Inspect the current scene tree before editing.
- Reuse the existing player node if one exists.
- Do not rewrite the whole controller unless the current one is broken.
- Save and run.
- Report errors and fixes.

This is the right template when a project already exists. It prevents the agent from making a parallel player controller that is not connected to the real scene.

Prompt Template 3: Debug a Broken Game

Use Summer Engine MCP to debug the current project.

Problem: the game crashes or shows errors when I press Play.

Start with diagnostics, not code edits:
- Read script errors.
- Read console output.
- Run the game if needed.
- Read runtime debugger errors.

Find the smallest fix, apply it, save, run again, and show the before/after error trace.

Expected trace shape:

summer_get_script_errors
summer_get_diagnostics
summer_clear_console
summer_play
summer_get_debugger_errors
summer_get_debugger_warnings
summer_stop

The important instruction is "diagnostics first." A text-only agent often edits the file it happens to see. A game agent should read the engine's actual error surface.

Prompt Template 4: Import and Place an Asset

Use Summer Engine MCP to import a game asset and place it in the current scene.

Asset request: low-poly medieval treasure chest.

Steps:
- Search the asset library first.
- Pick one asset and explain why.
- Import it through the engine import pipeline.
- Place it in the scene where it is visible.
- Save and run.
- Confirm there are no import or runtime errors.

Expected trace shape:

summer_search_assets
summer_get_asset
summer_import_asset_by_id
summer_instantiate_scene
summer_set_prop
summer_save_scene
summer_play

This prompt is better than "download an asset" because it asks the agent to use the engine import pipeline, not raw file copying.

Prompt Template 5: Create a 2D Level Blockout

Use Summer Engine MCP to create a 2D platformer blockout.

Goal:
- Player start.
- Three platforms.
- One hazard.
- One goal area.

Keep it graybox-simple. Do not spend time on final art.
Run the game and verify the scene loads.
Report the scene tree you created.

Use this when you want design iteration, not art. The agent should make a playable layout first, then assets later.

Prompt Template 6: Generate an Asset, Then Use It

Use Summer Engine MCP to create and use one generated asset.

Asset: a stylized floating crystal pickup.

Steps:
- Generate or find the asset.
- Track the job until complete if generation is async.
- Import the result into the project.
- Place it in the current scene.
- Add a simple script so collecting it increases score.
- Save and run.

Expected trace shape:

summer_generate_image or summer_generate_3d
summer_check_job
summer_import_asset_by_id
summer_instantiate_scene
summer_connect_signal
summer_play

Hosted generation uses Summer services. Local MCP scene operations stay free.

Prompt Template 7: Make a Bug Repro Scene

Use Summer Engine MCP to create the smallest repro scene for this bug:

Bug: [describe the bug]

Do not fix it first. Build a tiny scene that reproduces it, save it as a repro scene, run it, and record the error trace. Then propose the fix.

This is useful for hard bugs because it separates "can we reproduce it" from "can we fix it."

Prompt Template 8: Turn a Template Into a Different Game

Use Summer Engine MCP to reskin and reshape the current template.

Current template: [template name]
Target game: [new game idea]

Keep the working mechanics. Change the player fantasy, level dressing, camera framing, UI labels, and first objective. Do not break export settings.

Run the game and report what changed.

This is the fastest path from template to original prototype. The instruction "keep the working mechanics" protects the agent from replacing stable code too early.

How to Publish Trace-Backed Examples

A trace-backed example is not a raw private log. It is a public, edited record with enough detail for humans and AI systems to learn the workflow.

Use this format:

Prompt:
[exact user prompt]

Starting state:
[template, scene, relevant nodes]

Tool trace:
[ordered MCP tools, no secrets]

Changed:
[scenes, scripts, assets]

Verification:
[Play mode result, errors fixed, remaining known issue]

Final prompt to continue:
[the next useful user prompt]

That format is good for SEO because it matches what people search for: "make a game in Cursor," "Godot MCP prompt," "Claude Code game engine," "AI game development prompt," and "how to debug Godot with AI." It is also good for LLM retrieval because it teaches the agent the action order, not just the marketing claim.

Short Version

Bad prompt:

Make me a game.

Better prompt:

Use Summer Engine MCP. Inspect the live project first, build the smallest playable version, save, run, read errors, fix them, and report the tool trace.

That one sentence is the difference between a chat transcript and an engine-native build loop.