Chapter 7 of 15 14 min intermediate

Prompt Recipes

Prompts that actually work

Verified against a working setup on 2026-08-10

The difference between MCP being useful and being a novelty is almost entirely prompt shape. The pattern that works: tell it to look first, decide second, change third — and make each step something you can check.

Debugging

This is where MCP earns its setup time. No copying stack traces, no describing your hierarchy.

Console errors
text 
Read my Unity console. For each error, open the file it
points at, explain the actual cause, and propose a fix.
Do not change anything yet - show me the diff first.
3 lines
Runtime behaviour
text 
My player falls through the floor when it spawns.
Inspect the player GameObject and the floor in the open
scene, check their colliders, rigidbodies and layers,
and tell me which of them is misconfigured.
4 lines
Note the shape of that second one: it names the symptom, points at where to look, and lists what to check. Compare it to "why does my player fall through the floor" — which gets you a generic checklist you could have found on any forum.

Understanding a project

Useful when you return to something after six months, or inherit a project from someone else.

Orientation
text 
Search my project for all MonoBehaviours that reference
GameManager. Summarise how they use it, and flag any that
would break if GameManager were destroyed on scene load.
3 lines
Convention check
text 
Look at five scripts in Assets/Scripts/Player. Describe the
conventions they follow - naming, serialisation, how they
get component references - so you can match them in new code.
3 lines
That second prompt is worth running at the start of any session where the model will write code. Models default to generic Unity style; explicitly telling it to match your existing conventions is what stops the codebase drifting.

Scene work

Scene edits are the riskiest thing MCP does, so structure the prompt to keep them reviewable.

Audit before acting
text 
List every GameObject in the open scene that has a Collider
but no Rigidbody, and is not marked static. For each, tell me
whether it looks intentional. Do not change anything.
3 lines
Bounded change
text 
In the open scene only, find every enemy prefab instance
with maxHealth below 10 and set it to 10.
List exactly what you changed when you are done.
3 lines
"In the open scene only" and "list what you changed" are not politeness. Without a scope, the model may search the whole project; without a report, you cannot review the edit. Both belong in every scene-editing prompt.

Profiling (official relay only)

The relay exposes profiler data, which turns performance work from guesswork into reading numbers.

Frame time
text 
Take a profiler capture while I play for a few seconds, then
tell me the five most expensive samples by self time and
which scripts they come from.
3 lines
Allocation hunting
text 
Check GC allocations over the captured frame range.
Identify anything allocating every frame and show me the
line responsible.
3 lines
Per-frame allocations are exactly what the Object Pool pattern exists to eliminate, and they are tedious to find manually. This is the single most valuable thing the official relay does that the community server cannot.

Writing new code

Grounded in the project
text 
Read Assets/Scripts/Player/PlayerController.cs and
Assets/Scripts/Combat/Health.cs first. Then write a
StaminaSystem MonoBehaviour that matches their style,
using SerializeField for tunables. Create the file,
then check the console compiled clean.
5 lines

The last clause matters. "Then check the console compiled clean" closes the loop — the model verifies its own work instead of handing you code that does not build.

Prompts that reliably fail

Instead ofTryWhy
"Fix all the errors""Read the console, explain each error, propose fixes"Forces diagnosis before edits.
"Make my game run faster""Profile it and show the five worst samples"Otherwise you get generic advice.
"Clean up my scene""List objects with X, then ask me""Clean up" has no definition.
"Build an inventory system""Read these two scripts, then write the item class"Big asks drift from your conventions.
"Refactor this""Extract the input handling into its own component"Name the change you want.

The three-step habit

Look, decide, change

Almost every good MCP session follows the same rhythm. Ask it to look and report. Read that report and decide what should happen. Then ask for a bounded change with a summary at the end.

It feels slower than asking for the outcome directly, and it is — by about a minute. It also removes nearly every case where you discover an hour later that something quietly rewrote a prefab you cared about.

The reason is simple: the report step is where you catch a wrong mental model before it becomes a wrong edit. If its description of your scene is off, nothing it does next will be right.

What to take away

  • Tell it where to look; do not make it guess.
  • Ask for a report before any change.
  • Always scope scene edits and demand a summary.
  • Have it read existing scripts before writing new ones.
  • End code prompts with "check the console compiled clean".
  • Name the refactor you want rather than saying "refactor".