Unity and DevelopmentUnity and codeIntermediate~7 min

The Controlled MCP Change Loop

Snapshot

~85 sec

A controlled MCP change follows inspect → plan → approve → change → test → review. Read current evidence before proposing an edit, name the exact target and expected diff, approve one bounded call, run deterministic checks, and compare post-change evidence. Stop or roll back when assumptions no longer hold.

You will learn

Build a six-stage change loop from pre-edit evidence to post-change review.
Separate a proposed diff and approval from the mutating call itself.
Define deterministic checks plus explicit stop and rollback boundaries.

Target outcome

You can wrap a narrow MCP mutation in an inspectable workflow that detects stale assumptions and produces reviewable evidence.

01
Six gates around one change
- Inspect
  Read the exact current target, value, relevant errors, and repository or scene state.
- Plan
  State one intended diff, expected result, checks, and stop conditions.
- Approve
  Authorize the named tool and exact arguments after reviewing the proposal.
- Change
  Apply only the approved mutation and preserve a recovery boundary.
- Test
  Run deterministic checks that can fail independently of the model's explanation.
- Review
  Compare before, intended diff, actual diff, checks, and current project evidence.
02
Close the loop with post-change evidence
Each stage has a distinct responsibility. Review can accept the result, request a new bounded plan, or restore the known before state.
1. Inspect
  Read target-dummy-01 and confirm active is currently true.
  inspect_object(id: "target-dummy-01")
  grounds
2. Plan
  Propose active true to false, one property only, with expected checks.
  asks
3. Approve
  Review target ID, before value, after value, tool, and rollback.
  permits
4. Change
  Invoke the one approved write without saving unrelated content.
  set_object_active(id: "target-dummy-01", active: false)
  must pass
5. Test
  Re-read the object, run scene validation, and inspect the exact diff.
  reports
6. Review
  Accept only if actual state and checks match the approved plan.
accept, revise, or rollbackReview → Inspect
Each stage has a distinct responsibility. Review can accept the result, request a new bounded plan, or restore the known before state.
Reading order
1. Inspect
  Read target-dummy-01 and confirm active is currently true.
  inspect_object(id: "target-dummy-01")
2. Plan
  Propose active true to false, one property only, with expected checks.
3. Approve
  Review target ID, before value, after value, tool, and rollback.
4. Change
  Invoke the one approved write without saving unrelated content.
  set_object_active(id: "target-dummy-01", active: false)
5. Test
  Re-read the object, run scene validation, and inspect the exact diff.
6. Review
  Accept only if actual state and checks match the approved plan.
Connection explanations
1. Inspect → Plan (grounds)
  A plan is bounded by observed current state rather than a stale assumption.
2. Plan → Approve (asks)
  Approval reviews a visible target, diff, checks, and recovery boundary before mutation.
3. Approve → Change (permits)
  Authority applies to this exact call and does not grant future or broader writes.
4. Change → Test (must pass)
  The write is incomplete until deterministic checks inspect its observable result.
5. Test → Review (reports)
  Test output and actual diff give review evidence independent of a success claim.
6. Review → Inspect (accept, revise, or rollback)
  A revision starts from fresh evidence; a failed boundary returns to the known before state when possible.

One-shot mutation versus controlled loop

Approach	Before evidence	Authority	Verification	Failure boundary
Find and fix itA broad tool searches an invented scene, changes likely matches, and reports success.	No stable ID, expected value, or initial diff anchors the mutation.	A vague request is treated as permission for every discovered edit.	The same operation that mutated the project also writes the success narrative.	There is no explicit stop on stale state, extra diff, test failure, or connection loss.
Inspect, approve, change, proveOne exact invented object and property move through the six-stage loop.	Stable target ID, current value, scene, and relevant validation state are recorded.	Approval names one tool, one target, one expected current value, and one new value.	A fresh read, deterministic scene check, and actual diff confirm or reject the result.	Stale target, unexpected diff, failed check, or lost transport triggers stop or rollback.

Continue next
High-Value Unity MCP Workflows
Apply the generic control loop to concrete console, scene, prefab, build, and test work.
04
Make the proposal and stop boundary reviewable
Invented evidence bundle for one reversible scene property. It makes the target, before state, proposed diff, required approval, checks, and rollback visible before the call.
Languagetext
```
TARGET
Scene: PracticeRoom
Object ID: target-dummy-01
Property: active

BEFORE
active = true

PROPOSED DIFF
active: true -> false

APPROVAL
Required for set_object_active(target-dummy-01, false)

DETERMINISTIC CHECKS
- Object ID still resolves
- Expected current value is true
- Scene diff contains only the approved property

STOP / ROLLBACK
Stop on stale target, extra diff, failed check, or lost connection.
Rollback by restoring active = true before any save.
```
Code annotations
1. Lines 1-7
  Anchor the proposal
  Scene, stable object ID, property, and observed value define the exact before state.
  Effect: The write can reject execution if the target or value changed after inspection.
2. Lines 9-13
  Separate proposal from authority
  The expected diff is visible before the named mutating call is approved.
  Effect: Approval remains bounded to one reviewed change.
3. Lines 15-18
  Use deterministic checks
  Target resolution, expected current value, and exact diff can fail without asking a model to judge itself.
  Effect: The workflow catches stale or expanded changes before review accepts them.
4. Lines 20-22
  Know when to stop
  Unexpected state, extra diff, failed check, or lost connection ends the attempt.
  Effect: A reversible property can return to the recorded before value before any save.
Expected output
Reviewable completion evidence
The post-change object read shows active false, the actual diff contains only that property, all declared checks pass, and the reviewer deliberately accepts or rolls back the result.
Warning
MCP does not enforce this loop by itself
MCP can expose the reads and writes used by this workflow. It does not require inspection first, obtain meaningful human approval, run the right tests, compare diffs, or roll back a bad result. The host, server design, project rules, deterministic scripts, and reviewer must implement and enforce those boundaries.
Stop a stale change
Inspection found target-dummy-01 active true. The plan to set it false was approved, but another edit changed its stable target state before execution. The write tool now sees an unexpected current value. What should happen?
Expected reasoning
Stop without applying the mutation. The approved plan depended on an observed before state that is no longer true. Re-inspect the exact target, explain the stale assumption, and create a new bounded plan if the change is still needed. Do not reinterpret the old approval as permission for a different current state.

Go deeper

Unity MCP: Get startedUnity's official connection, approval, read-first console check, and verification workflow.
Unity Manual: Test FrameworkCurrent Unity reference for Edit mode and Play mode test verification.

You will learn

Target outcome

Six gates around one change

Inspect

Plan

Approve

Change

Test

Review

Inspect

Plan

Approve

Change

Test

Review

Reading order

Connection explanations

One-shot mutation versus controlled loop

Code annotations

Anchor the proposal

Separate proposal from authority

Use deterministic checks

Know when to stop

Stop a stale change

Go deeper