A Unity movement script can compile successfully while the player still refuses to move. The component might be missing from the GameObject, an Inspector reference might be empty, or the project might use a different input system. Asking Claude to generate C# addresses only part of that problem. Connecting it to the running Unity Editor gives it a way to investigate the rest.

Using Unity with Claude combines two approaches. A Unity MCP bridge can expose scene information, GameObjects, components, assets, Console messages, and Editor operations through structured tools. With a compatible setup, Claude can inspect the project, make targeted changes, and check the results instead of leaving you to transfer every instruction manually.

Computer Use adds interaction with the visible interface. Where supported and enabled, Claude can inspect screenshots, operate approved Unity windows, and check workflows such as navigating a menu or spotting clipped UI in the Game View.

Neither approach makes an entire game build itself. This guide focuses on connecting Claude to Unity, developing a small feature, and verifying it through compilation, tests, and visual checks, with clear boundaries around what the assistant can change.

Give Claude Access to the Editor, Not Just Your Scripts

A Unity project has several layers of information, and Claude needs the right access for the task. Reading a C# file reveals what a component is supposed to do. It does not establish whether that component is attached to the correct object, enabled, or configured properly in the active scene.

Think of access in three levels:

• Project files: scripts, package configuration, and assets that a coding assistant can inspect or edit.

• Live Editor state: scene hierarchy, component values, selections, and Console messages exposed by a Unity MCP server.

• Visible behavior: what appears in the Game View and how the interface responds during interaction.

These levels complement each other. For example, Claude might read a health script, use MCP to discover that the player’s health bar reference is unassigned, then inspect the Game View to check whether the corrected UI appears.

Source: Unity Documentation

The connection typically follows this path:

Claude → MCP server → Unity Editor package → scene, assets, and Console

However, “Claude” does not describe one interchangeable interface. Claude Desktop Chat can use configured MCP tools, while Claude Code provides a coding workflow for editing project files and running development commands. Configure the bridge for the client you actually intend to use.

Computer Use is a separate capability with its own platform requirements and permissions. Receiving a screenshot through MCP lets Claude analyze an image; it does not automatically give it mouse and keyboard control over Unity.

Choose a Unity MCP Bridge and Prepare the Project

Unity MCP bridges are third-party integrations, not a standard feature included with every Unity installation. Choose one implementation and follow its documentation consistently: installation steps, dependencies, and tool names are not interchangeable.

This guide uses CoplayDev’s Unity MCP, which connects an Editor package to an MCP server. Its documented requirements include Unity 2021.3 LTS or newer, Python 3.10+, and uv for the Python server. Installing the Editor package through a Git URL also requires Git.

Ivan Murzak’s Unity MCP is another option, with a different server architecture and a documented Unity 2022.3+ requirement. It can suit projects needing custom C# tools, but its setup should not be mixed with CoplayDev’s instructions.

Before connecting Claude, prepare a project that already opens and compiles. Otherwise, existing package or script errors can obscure whether the bridge itself works.

Use a short preflight checklist:

• Save the active scene and create a version-control checkpoint.

• Resolve existing compilation errors.

• Identify the render pipeline: Built-in, URP, or HDRP.

• Check whether the project uses the legacy Input Manager, the Input System package, or both.

• Note the active build platform and relevant installed packages.

These details directly affect generated changes. A material needs a shader compatible with the render pipeline; a movement script needs an input approach supported by the project.

Start in a duplicate scene or a small test project. Keep the initial scope explicit: Claude may inspect the project and propose changes, but should ask before deleting assets, replacing project settings, or modifying existing gameplay systems.

Connect Claude to Your Running Unity Project

For CoplayDev’s bridge, installation starts inside Unity. Open Window → Package Manager, choose the option to add a package from a Git URL, and enter:

This follows the project’s installation guide. For a reproducible team setup, pin a compatible release rather than relying indefinitely on a moving branch.

Source: Unity Documentation

Once Unity finishes importing the package, open Window → MCP for Unity. Use the setup interface to check dependencies and configure your chosen Claude client. Resolve missing Python or uv dependencies before troubleshooting the connection itself.

Source: CoplayDev

Configure the Client You Will Actually Use

Claude Desktop and Claude Code are separate MCP clients. Connecting one does not automatically configure the other.

For Claude Desktop, use the bridge’s supported Desktop configuration workflow. Its local stdio setup launches the MCP server as a process that communicates with Claude; it is not the same configuration as connecting to an HTTP endpoint.

For Claude Code, the bridge supports HTTP or stdio configurations. If you choose HTTP, start the server through the Unity integration and copy the endpoint shown in its configuration. Then use Claude Code’s MCP configuration command:

Replace YOUR_MCP_ENDPOINT with the actual address. Do not assume that an example port matches your running server. Open /mcp in Claude Code to check connection status and available tools.

Verify the Project Before Making Changes

A saved configuration does not prove that Claude can reach the intended Unity Editor. The server must be running, the Editor package must be connected, and requests must target the correct project.

If multiple Unity Editors are open, explicitly select the intended instance using the bridge’s instance-selection mechanism. Then begin with a read-only request:

Compare the response against Unity. Scene names and root objects should match what is actually open, not a plausible example project.

If the connection works but expected tools are missing, check the bridge’s enabled tool groups. Testing, animation, and other specialized operations may require additional groups to be activated.

Keep this verification separate from feature development. First establish that Claude can inspect the correct Editor; then authorize a small, clearly bounded change.

Build One Small Feature Before Asking for a Whole Game

Your first task should exercise the connection without putting existing gameplay at risk. A separate movement test scene works well: a floor, a player capsule, and a camera are enough to test object creation, script editing, component configuration, and runtime behavior.

Start with a bounded request:

The important detail is the order. Claude should inspect the project before choosing an input API or shader. It should also distinguish creating a script from attaching and configuring that script in the scene.

Define What “Working” Means

Give Claude observable acceptance criteria rather than asking it to “make a good controller.” For this test, the player should move across the floor, remain supported by collisions, and stay visible through the follow camera. The Console should show no new errors during the test.

Through the bridge’s component tools, Claude can inspect or update component configuration. That helps catch mistakes such as an unassigned target reference or a movement component attached to the wrong object.

However, the implementation still needs review. A controller that changes a Transform directly behaves differently from one using a CharacterController or Rigidbody. Ask Claude to explain its choice and keep it appropriate to the prototype.

Verify Before Expanding

After scripts compile, inspect the hierarchy and relevant Inspector values. Then enter Play Mode and check movement, collisions, and camera framing. Use MCP screenshots or approved Computer Use where available; if keyboard interaction is unavailable, perform that part manually.

Source: Unity Documentation

Do not treat a screenshot of a capsule as proof that movement works. Likewise, successful compilation does not establish that the camera follows correctly.

Once the small scene passes these checks, save it and create another checkpoint. You now have a verified starting point for adding a jump, collectible, or menu without changing several systems at once.

Close the Loop: Compile, Read the Console, and Run Tests

A script edit is not a completed Unity task. The Editor must import the change, finish compiling, and execute the relevant behavior before Claude can reasonably report success.

Make that verification loop part of the request:

Edit → refresh/import → wait for compilation → inspect Console → test → report

Avoid asking Claude to make several additional changes while Unity is still processing the first one. Compilation and domain reloads can temporarily interrupt Editor tools, making premature follow-up requests misleading.

Separate Three Types of Failure

Compilation errors prevent the code from building. Runtime errors occur when code executes, for example, when an unassigned reference is accessed. Behavioral failures can happen without either: a pause menu may appear while gameplay continues underneath it.

The bridge’s Console-reading tool helps investigate the first two, but a clean Console does not prove correct behavior.

Source: Unity Documentation

Use a narrow repair prompt:

Run Tests and Wait for the Result

Where the project has suitable automated tests, ask Claude to run the relevant subset. EditMode tests can check logic and Editor-side operations; PlayMode tests can exercise behavior that depends on the running Unity environment.

Source: Unity Test Framework Documentation

CoplayDev’s run_tests tool is asynchronous. It returns a job_id, which Claude must use with get_test_job to retrieve progress and the final result. Receiving a job identifier means testing started, not that tests passed.

Request a final summary containing the tests run, pass/fail results, remaining Console errors, and any behavior that still needs manual inspection. If no relevant tests exist, Claude should say so rather than presenting compilation as equivalent coverage.

For the movement prototype, that means combining code checks with a runtime check of movement, floor contact, and camera behavior. Each answers a different question.

Let Claude Check What the Player Actually Sees

Some Unity problems become obvious only through interaction. A button can have the correct label and an assigned callback yet open the wrong panel. A menu can look fine at one aspect ratio but hide its controls at another. Computer Use can help investigate these visible failures after the underlying scripts compile.

Check availability for your chosen Claude interface first. The current Computer Use documentation distinguishes Desktop support on macOS and Windows from Claude Code CLI support on macOS. The CLI capability requires an eligible Pro or Max account and an interactive session; it is disabled until enabled through /mcp. Grant the required operating-system permissions and approve Unity when prompted.

Source: Anthropic

The following are practical workflows to try, not guarantees that Claude will reliably operate every Unity project.

Click Through a Menu Smoke Test

Start with a short, repeatable sequence rather than an open-ended request to “playtest the game.”

Separating observation from repair makes findings easier to review. Claude should report what it actually checked, including interactions it could not complete.

Reproduce UI Problems at Different Aspect Ratios

Ask Claude to inspect the Game View at specified ratios, such as 16:9 and 9:16, and compare button visibility, text wrapping, and overlapping panels. If controls disappear, have it capture the failing state before investigating anchors, layout settings, or scaling.

A Game View screenshot through MCP may be sufficient for static inspection. Choose the capture method carefully: rendering an individual camera can omit Screen Space Overlay UI. Analyzing that screenshot is visual inspection, not Computer Use; screen control is needed when Claude must operate the interface.

Handle an Editor Window Without a Dedicated Tool

A third-party level-design or dialogue package may expose its workflow through a custom Editor window rather than the bridge’s tools. Computer Use offers a possible fallback for opening the window, inspecting controls, or reproducing a reported problem.

Keep permissions narrow. Specify which window Claude may use, what action it should attempt, and whether saving changes is authorized. Prefer structured MCP operations whenever they cover the task.

These checks complement automated tests; they do not replace them. Mouse-and-keyboard interaction is unsuitable for proving frame-perfect timing, deterministic physics, or comprehensive gameplay coverage. Use it to find visible problems and produce clear reproduction steps, then verify important behavior with repeatable tests.

Useful Unity Tasks Beyond the First Prototype

Once the connection is reliable, Claude can help with bounded production tasks, not just creating more objects. The strongest requests identify a specific asset or system, define what may change, and include a measurable result.

Audit Prefabs Before Fixing Them

Repeated objects often hide inconsistent component values or broken references. The bridge’s prefab and component tools provide a starting point for inspection.

Success means a report naming affected assets and properties, not a generic recommendation. Before authorizing repairs, distinguish changes to a prefab asset from overrides on individual scene instances. Updating the shared asset can affect every instance that inherits its values.

Source: Unity Documentation

Turn a Sprite Sheet Into a Testable Animation

For a 2D project, the manage_sprite tool supports grid slicing, AnimationClip creation, and AnimatorController setup.

Check frame order, playback speed, pivot consistency, and whether neighboring sprites bleed into the animation. A generated controller is only the setup; the visible result still needs inspection. Irregularly packed sheets may require a different slicing approach.

Source: Unity Documentation

Iterate on Camera Framing

Camera adjustments benefit from combining structured changes with screenshots.

Evaluate the same scene state in both captures. If the project uses Cinemachine, Claude should inspect the installed package and existing rig before changing its configuration.

Investigate Performance With Measurements

The bridge also exposes profiling tools. Use them to investigate a specific slowdown, not to request vague “optimization.”

Record the hardware, workload, and whether measurements come from the Editor or a player build. A higher FPS number in one screenshot does not establish an improvement. Compare equivalent runs and preserve gameplay behavior while evaluating the change.

Source: Unity Documentation

When the Workflow Breaks—or a Change Does Not Persist

A failed request does not always mean Claude needs different code. First identify whether the problem belongs to the connection, the Editor, or the project.

Claude reports unfamiliar scene objects. Check the selected Unity instance. With multiple Editors running, explicitly target the intended project and repeat a read-only inspection before authorizing changes.

Tools stop responding after a script edit. Unity may be compiling or reloading assemblies. Wait for the Editor to settle, then inspect connection status and the Console. Do not repeatedly submit the same object-creation request: an earlier operation may have completed despite a delayed response.

New materials appear pink. Inspect the assigned shader and render pipeline. Repair the material using a compatible shader rather than changing the project’s pipeline to accommodate a generated asset.

A successful test seems to disappear. Check whether Claude changed scene properties during Play Mode. Unity normally resets those runtime changes when Play Mode ends. Script and asset edits are different; they should not be treated as automatically reversible. See Unity’s Game View documentation.

A test has no final result. Retrieve the asynchronous job’s status rather than treating its initial identifier as a pass.

An expected tool is unavailable. Check the installed bridge version and enabled tool groups before asking Claude to invent an alternative command.

After a successful repair, stop Play Mode, verify persistent scene values, and save intentionally. Preserve Unity’s .meta files when moving or committing assets; losing their identifiers can break references.

Keep checkpoints small enough to review. Before a bulk rename, prefab-wide change, package update, or deletion, require an explicit plan and approval.

Keep Unity and Claude Together on Vagon Cloud Computer

An AI-assisted workflow still depends on the machine running Unity. Claude can propose a fix quickly, but asset imports, shader compilation, demanding scenes, and player builds can leave an underpowered laptop struggling to keep up.

Vagon Cloud Computer for game development gives you access to a high-performance cloud desktop without buying a new workstation. Run Unity on the cloud machine and access your development environment from a lightweight laptop or Chromebook. Choose resources suited to your project: GPU capacity matters for rendering-heavy scenes and Game View previews, while CPU performance and memory matter for imports, compilation, and builds.

For this workflow, install Unity, the MCP bridge, and your chosen Claude client in the same cloud environment. Keeping them together simplifies access to project files and the running Editor; it also avoids treating a local MCP address as though it points to another machine.

Computer Use requires additional care. Confirm that your Claude client supports screen control on the cloud operating system and can access the Unity session. Unity licensing, Claude subscriptions, and integration setup remain separate requirements.

Vagon strengthens the Unity side of the workflow, it does not accelerate Claude’s cloud-hosted model inference or eliminate network latency. Use a stable connection, and validate timing-sensitive gameplay on suitable target hardware.

When local hardware becomes the bottleneck, move your Unity workspace to Vagon and give your development loop room to grow.

FAQs

Can Claude directly control Unity?

Yes, through a compatible MCP bridge that exposes Editor operations. Available tools depend on the integration and enabled tool groups. Computer Use provides a separate way to interact with approved Unity windows through thhttps://app.vagon.io/registere visible interface.

Should I use Claude Desktop or Claude Code?

Use Claude Desktop for a conversational MCP workflow. Claude Code is useful when the task combines project-file editing, development commands, and Editor tools. Configure the bridge for your chosen client; their connections and Computer Use requirements are not interchangeable.

Is Unity MCP an official Unity feature?

The bridges discussed here are third-party projects. Installing one does not mean Unity Technologies officially supports its tools. Check the repository’s compatibility requirements and maintenance status before using it in a production project.

Do I need Computer Use if MCP can capture screenshots?

Not necessarily. MCP screenshots can support visual inspection, while structured tools can change scene properties. Computer Use becomes useful when Claude needs to click through a menu or operate an Editor window that lacks a suitable tool.

Can Claude playtest my game?

It can assist with bounded checks, such as navigating menus, reproducing layout problems, and inspecting runtime errors. That is not comprehensive playtesting. Automated tests and human evaluation remain important, particularly for timing, game feel, and platform-specific behavior.

Will changes made during Play Mode be saved?

Scene and component changes made during Play Mode normally reset when you exit. Script or asset edits can persist. Have Claude distinguish temporary runtime adjustments from intentional saved changes.

Can Claude build an entire Unity game?

It can help develop individual systems and connect them incrementally. A complete game still requires design decisions, assets, integration, performance testing, and review. Small tasks with clear acceptance criteria are easier to verify.

Can I use this workflow on a cloud computer?

Yes, provided Unity, the bridge, and your Claude client are compatible with the environment. Configure screen-control permissions separately and account for streaming latency during interactive checks.