Chapter 1 of 15 7 min beginner

What is Unity MCP

Letting an LLM drive the Editor

Verified against a working setup on 2026-08-10

Chat with an AI about Unity and it can only describe what to do. You still click every menu. MCP closes that gap: it gives the model a set of tools it can actually call, so it reads your real scene, writes real files, and reads your real console errors.

The protocol in one paragraph

The Model Context Protocol is an open standard for exposing tools to language models. A server advertises a list of callable functions; a client (your AI app) discovers them and lets the model call them. It is deliberately boring plumbing — the value is that any MCP client works with any MCP server.

A Unity MCP server exposes the Editor. The model gets functions like "list the GameObjects in this scene", "create a script", "read the console". Because MCP is a standard, the same Unity server works in Claude Code, Cursor, VS Code, and anything else that speaks it.

Three pieces, always

Every Unity MCP setup

Piece	What it is	Note
`The client`	`Claude Code, Cursor, VS Code`	Where you type. Holds the model.
`The MCP server`	`A process on your machine`	Advertises the Unity tools.
`The Unity side`	`A package inside the Editor`	Does the actual work in-Editor.

Missing the third piece is the most common failure. People configure the server in their client, see it connect, and assume it works — but with no Unity-side package listening, every tool call fails or returns nothing. Installing Unity MCP covers both halves.

What it can actually do

Concretely, with a working setup, this is the kind of thing that stops being manual:

Read the console. Paste nothing. It reads your compile errors and stack traces directly.
Inspect the scene. "Why is the player falling through the floor?" — it can check the colliders itself.
Write and edit scripts in your project, then check whether they compiled.
Create and wire GameObjects, set component values, build a test scene.
Search the project across thousands of assets without you naming files.

The read-only half is the underrated part. Even if you never let a model write anything, "read my console and scene" removes most of the copy-pasting that makes AI help tedious.

What it cannot do

Worth being blunt, because expectations here run high:

It cannot play your game and judge it. It can enter play mode and read logs, but "does this feel good?" is not available to it.
It is not fast. Every tool call is a round trip. A task you could do in three clicks is usually quicker by hand.
It does not understand your intent beyond what you wrote. Vague prompts produce confidently wrong scene edits.
It will not build your game for you. Treat it as a very fast junior who has never seen your project before.

Is it worth setting up?

Task	Worth it?	Why
`Debugging a console error`	`Yes, clearly`	It reads the error and the file itself.
`Writing a new system`	`Yes`	It sees your existing conventions.
`Bulk scene edits`	`Yes, carefully`	Fast, but commit first.
`Moving one object`	`No`	Dragging it is faster.
`Art and feel decisions`	`No`	It cannot see or judge the result.

Two servers, not one

The thing most guides skip: "Unity MCP" is not one product. There is an official path built into Unity 6.3's AI Assistant package, and a community server that has existed for longer and works on older Unity versions.

They install differently, expose different tools, and their config is not interchangeable. Mixing instructions from both is why so many setups silently fail. The next chapter compares them properly.

What to take away

MCP is a standard for giving models callable tools.
A Unity setup is always three pieces: client, server, and a Unity-side package.
The biggest win is reading your real console and scene, not writing code.
It is slow for small tasks and cannot judge how anything feels.
There are two different Unity MCP servers — pick one deliberately.