📑 Open contents

Documentation

Everything you need to know about how Editor Eye works and how to get the most out of it. Just talking to an AI moves your Unity Editor — once you know what is happening behind the scenes, you'll get a lot more out of every conversation.

🔧

Setup

Getting Editor Eye running takes two steps: drop the package into Unity, then register Editor Eye with your AI client. You only do this once — updates roll out automatically afterwards.

1-1

Install Editor Eye

Head over to the install page and grab the .unitypackage file. Drop it into your Unity project and you're ready to be driven by an AI.

  1. Double-click the downloaded .unitypackage (or use Assets → Import Package → Custom Package… from the Unity menu) to import it.
  2. Once Unity finishes recompiling, setup is complete automatically. You'll see Window → Editor Eye in the menu bar — that means it worked.
  3. Open Window → Editor Eye → Settings, paste the license key from your dashboard, and click Connect.
💡 To upgrade later, just import the new .unitypackage the same way. Your settings carry over.
1-2

Configure Claude Desktop (one-time)

If you're using Claude Desktop, add Editor Eye to its config file as a tool Claude can call. Just paste the JSON below.

Config file location: %APPDATA%\Claude\claude_desktop_config.json (Windows) / ~/Library/Application Support/Claude/claude_desktop_config.json (Mac)

{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer your-license-key"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ Replace {username} with your Windows username.
editor-eye-windows is Windows-only. Skip it on Mac / Linux.

💡 Find your license key on the dashboard. The editor-eye server is reached over plain HTTP, so you don't need Node.js or any npm packages installed locally.
You won't need to touch this config again. editor-eye (cloud) is rolled out server-side, and editor-eye-windows-cli.exe updates itself every time Unity starts.
1-3

Configure Claude Code CLI (one-time)

If you live in the terminal with Claude Code, add the same block to the mcpServers section of ~/.claude/settings.json. You can drive Unity without ever leaving your editor.

{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer your-license-key"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

Restart Claude Code and the editor-eye tools become available.

📝 Where to find your license key: after you sign up free, look in the "License Key" panel on the dashboard.
1-4

Set up editor-eye-windows Windows only

🪟 This section is for Windows users. On Mac / Linux editor-eye-windows won't run — just omit its block in 1-2 / 1-3.

editor-eye-windows is your local Windows sidekick that runs directly on your PC. It handles things that no cloud can reach — screenshotting the Unity Editor window as-is, bringing it to the foreground, killing it when it hangs. The "Unity right in front of you" jobs.

📦 The CLI installs itself

Import the .unitypackage and launch Unity. editor-eye-windows-cli.exe is copied to the path below automatically. No manual install needed.

C:\Users\{username}\AppData\Local\EditorEye\editor-eye-windows-cli.exe

It's also replaced with the latest build every time Unity starts up, so version drift never accumulates.

⚙️ Add it to your MCP config

Drop the following block into the config file from 1-2 / 1-3 (swap {username} for your real Windows username).

"editor-eye-windows": {
  "command": "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
  "args": ["mcp-server"]
}

✅ Smoke test

  1. Launch the Unity Editor (this is what installs editor-eye-windows-cli.exe)
  2. Restart Claude Desktop / Claude Code so they re-read the MCP config
  3. Ask the AI: "Use editor-eye-windows to get the Unity window title."
  4. If the title comes back, you're set
Sections 1-5 to 1-8 are informational. The only clients we officially verify and support today are Claude Code and Claude Desktop. Editor Eye follows the MCP standard, so other MCP-compatible clients may also connect — but actual behavior depends on each client's MCP implementation. Try at your own risk.
1-5

Configure Cursor

If your version of Cursor supports MCP, adding Editor Eye to the config may let you drive Unity from the Cursor chat. (We haven't verified this ourselves.)

  1. Open .cursor/mcp.json in your project root (for per-project use) or ~/.cursor/mcp.json in your home directory (for every project).
  2. Paste the same block shown for Claude Desktop in 1-2 — the mcpServers shape is identical.
  3. Restart Cursor and the editor-eye tools become available.
{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer your-license-key"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ Exact paths and enablement steps may change between Cursor versions — cross-check with the Cursor docs.

1-6

Configure GitHub Copilot (VS Code)

On VS Code 1.99 or later with the GitHub Copilot MCP feature enabled, the following config may let you call Editor Eye. (We haven't verified this ourselves.)

  1. In VS Code settings.json, enable "github.copilot.chat.mcp.discovery.enabled": true.
  2. Create .vscode/mcp.json in your project and paste the same content as 1-2.
  3. Restart VS Code and Editor Eye tools should be callable from Copilot Chat.
{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer your-license-key"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ MCP setting keys and enablement flags shift around as VS Code / Copilot evolve — cross-check with the VS Code docs.

1-7

Configure Gemini CLI

If your Gemini CLI build supports MCP, the snippet below may get you connected. (We haven't verified this ourselves.)

  1. Open ~/.gemini/settings.json (create it if missing).
  2. Add the same mcpServers block as 1-2.
  3. Restart Gemini CLI and the editor-eye tools should appear.
{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer your-license-key"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ Paths and key names may change between Gemini CLI versions — check the Gemini CLI repo.

1-8

Configure OpenAI Codex

If the OpenAI Codex CLI supports MCP, this config may get you connected. (We haven't verified this ourselves.)

  1. Add the MCP server definition to ~/.codex/config.toml (or pass it via the CODEX_MCP_SERVERS env var).
  2. The shape mirrors the Claude Desktop mcpServers structure, just in TOML.
  3. Restart Codex CLI and Editor Eye tools should be discovered.
# Append to the mcp_servers section of ~/.codex/config.toml
[mcp_servers.editor-eye]
url = "https://api.editor-eye.app/mcp"
headers = { Authorization = "Bearer your-license-key" }

[mcp_servers.editor-eye-windows]
command = "C:/Users/{username}/AppData/Local/EditorEye/editor-eye-windows-cli.exe"
args = ["mcp-server"]
💡 The shape is essentially identical across clients. Add an editor-eye entry under mcpServers — the file format (JSON / TOML / etc.) and exact location is the only thing that differs. Check each client's docs for the specifics.

📐

Technical Reference

Editor Eye runs as two components that play different roles. Together they give you "works on every OS" convenience plus "Windows can do more" depth.

2-1

Two-layer MCP architecture

Every instruction from the AI reaches Unity through one of two paths: editor-eye (cloud route) or editor-eye-windows (local route). Reading the scene, editing GameObjects, running scripts — those go through the cloud. Grabbing the screen, bringing windows forward — those stay local. The AI picks the right route for you.

AI (Claude Code)
  │
  ├─ editor-eye (all OS)
  │    └─ editor-eye-server (Railway cloud)
  │         └─ Unity Bridge (WebSocket)
  │              └─ Unity Editor
  │
  └─ editor-eye-windows (Windows only)
       └─ editor-eye-windows-cli.exe (local)
            └─ Unity Editor (direct IPC)

🌐 editor-eye

  • Every OS (Windows / Mac / Linux)
  • ✓ Reads Unity state and drives the Editor over the cloud
  • ✓ GameObject state, knowledge injection, all the main tools
  • ✓ Network required

🪟 editor-eye-windows

  • Windows only
  • ✓ Drives the Unity Editor directly via local IPC
  • ✓ Screenshots, window management, hierarchy reads
  • ✓ Network optional (works offline)
💡 Install both if you can. For things like "read the scene" or "run this code" the AI reaches for editor-eye; for "show me the screen" or "bring Unity to the front" it switches to editor-eye-windows. The selection is automatic.
2-2

Keeping the connection alive

Editor Eye keeps the bridge between your AI and Unity alive on its own. Brief network blips, Unity restarts — none of those require you to do anything. Just three things to keep in mind.

🎮

Keep the Unity Editor open while you work

Have Unity running before you ask the AI to do something. If Unity is closed, instructions have nowhere to land and they'll just hang.

🔄

If the bridge drops, just say "reconnect"

When the connection times out (flaky Wi-Fi, sleep, etc.), telling the AI "reconnect to Unity" is enough — it will re-establish the link automatically.

🔃

Unity restarts heal themselves

Even after closing and reopening the Unity Editor, Editor Eye reconnects on its own. Most of the time it's back within a few seconds.


📸

Sending Screenshots

Showing the AI your actual Unity screen lets it work with the visuals rather than guess. Editor Eye gives you two capture methods, each tuned for different situations.

Method 1

editor-eye's screenshot tool — every OS

gateway_core_screenshot grabs Unity's Game View or Scene View (the game itself, basically) and hands it to the AI. Since it works on Mac and Linux too, this is the one to try first.

# Example prompt to Claude
"Take a screenshot of the Game View and tell me what you see."

✓ Best for

  • Checking how the Game View looks
  • Working on Mac / Linux
  • Driving Unity over the network

⚠ Limits

  • Can't capture the full Editor (Game View only)
  • Outside Play Mode the output sometimes comes back black
💡 With gateway_scene_capture_with_camera you can pin down the camera's position and field of view. Perfect for things like "shoot straight down on the enemy" or "look forward from the character's eye level".
Method 2

editor-eye-windows's capture_window tool Windows only

capture_window grabs the entire Unity Editor window — Inspector, Hierarchy, Console and all. Ideal when you want the AI to "read the value on screen here" or "interpret this error message".

# Example prompt to Claude
"Capture the whole Unity window and tell me the current state."

✓ Best for

  • Visually inspecting Inspector values
  • Showing the AI an error or Console output
  • Checking state outside Play Mode
  • Verifying overall UI layout

⚠ Limits

  • Windows only (no Mac / Linux support)
  • Requires editor-eye-windows setup (see 1-4)

Method comparison

Aspect Method 1
screenshot (any OS)
Method 2
capture_window (Windows)
Supported OS All Windows only
What gets captured Game View / Scene View Whole Editor
Capture outside Play Mode △ (may be black)
Inspector / Console readout
Specify camera angle ✓ (capture_with_camera)

Domain Reload & Compile Polling

Every time you save a script in Unity, a "compile → Domain Reload" cycle kicks off. For a few seconds Unity wipes its in-memory state, which briefly drops the Editor Eye connection too. Editor Eye watches for this and reconnects the moment the reload finishes. You almost never need to do anything yourself.

4-1

What is Domain Reload?

When you save a .cs file, Unity recompiles your code, then runs Domain Reload. Roughly speaking, "Unity takes a quick nap and wakes back up with the new code in hand."

  • It's the step that makes your changes actually run inside the Editor
  • While it's happening, every bit of Unity's C# state (variable values, statics) resets
  • When it finishes, Unity comes back with the updated code in place
⏳ Project size matters: small to mid-sized projects finish in a few seconds, large ones can take 10–30 seconds.
4-2

How Editor Eye handles it

During Domain Reload, the WebSocket between Editor Eye and Unity drops for a moment. The thing is, Editor Eye is built to drop on its own and recover on its own.

  • When the disconnect is detected, it retries the connection every 2–3 seconds
  • The instant Unity wakes back up, the WebSocket reattaches
  • You don't have to ask the AI to "reconnect" — it's automatic
✅ In short: edit script → save → wait a few seconds → Editor Eye is back. That's the whole flow.
4-3

Knowing when the compile finished

If the AI rushes from creating a script straight into the next operation, it can hit Unity mid-reload. To avoid that, the AI uses a simple "wait briefly, then read the log" pattern.

  • Use gateway_core_get_logs to check for compile errors
  • Seeing [EditorEye] Bridge connected in the log means the reconnect already happened
  • When in doubt, the classic move is gateway_core_sleep(3000)get_logs
4-4

Recommended wait pattern

This is the three-step shape the AI naturally falls into after creating or editing a script. You don't have to nag it with "wait, then check errors" — it does this on its own.

# create script → wait for reload → verify
1. manage_script(action: create, ...) # write the script
2. gateway_core_sleep(ms: 3000) # wait for Domain Reload
3. gateway_core_get_logs(logType: Error) # check for errors
💡 3 seconds is a guideline. Tiny changes finish faster; large projects sometimes need a longer wait to feel safe.
4-5

When Domain Reload drags on

Large projects or projects with lots of assemblies can take 10–30 seconds to finish a Domain Reload. When that's your reality:

  • Stretch the wait (gateway_core_sleep(ms: 5000) to 10000)
  • Call get_logs a few times to look for the "all clear" line
  • Just tell the AI "wait for compile to finish, then check" — it'll retry automatically
⚠ If Bridge connected never appears no matter how long you wait, Unity is probably stuck on a compile error. Run get_logs(logType: Error) and look at what's broken.

🎮

Tips for Building Games

The more you use Editor Eye, the clearer it gets which collaboration patterns with the AI pay off. The tips below are small habits that compound in real production. The most important one: tell the AI what you want to happen, not how to do it step by step.

5-1

Describe the end state, not the steps

Instead of dictating fine-grained steps, just tell the AI what the world should look like when you're done. You'll arrive faster and with fewer mistakes. Leave the how to the AI.

❌ Step-by-step (slow)

"First, create a GameObject. Now add a Rigidbody. Set its mass to 2. Turn off gravity…"

✓ End-state (fast)

"On the Enemy object, add a Rigidbody with mass 2 and no gravity."

💡 The AI can use batch_execute to run several operations in one go. Stringing requests together as a single sentence ("do X and Y and Z") lets it bundle them for you.
5-2

Think in Action → Verify → Adjust

Editor Eye really shines when you keep the Action (execute) → Verify (check) → Adjust (correct) loop spinning quickly. Just add "and check it" to a request, and the AI grabs a screenshot or reads the log on its own to validate the outcome.

# A typical AVA cycle
1. Prompt: "Add a Bloom effect to the Main Camera."
2. The AI runs the operation.
3. The AI automatically grabs a screenshot to confirm.
4. If needed, you nudge it: "make it stronger."

Ways to speed AVA up:

  • 📸 Ask for screenshots often — just say "show me the current state" and the AI captures and reads the screen.
  • 📋 Get it to read logs — "check for errors" triggers an automatic log scan.
  • 🔍 Use the selection — pick a GameObject in Unity, then say "show me the state of the selected object" for a detailed dump.
5-3

Bulk work belongs in batch_execute

"Wire up NavMeshAgent on 50 enemies", "match lighting across every level" — repetitive jobs like these collapse into a single batch_execute call. What used to take hours by hand finishes in seconds.

# Example prompt
"For every GameObject in the Hierarchy named Enemy_*,
add a NavMeshAgent and set speed to 3.5."
✅ batch_execute integrates with Unity's Undo stack. If something goes sideways, just say "undo that" and the whole batch rolls back.
5-4

Try small, then scale up

Instead of applying a change to everything at once, prove it on a single object first, then roll it out. The AI naturally falls into this flow, and if you decide partway through that the approach is wrong, there's almost nothing to roll back.

Step 1

Apply the change to one test GameObject → confirm with a screenshot

Step 2

If it looks right, say "apply the same setup to everything else"

Step 3

batch_execute fans the change out → check the log for errors

5-5

When you're stuck, ask the AI to research first

Editor Eye ships with a Knowledge DB packed with Unity-specific lore — known bugs, workarounds, API quirks. When the AI gets stuck or an error refuses to go away, it taps this DB automatically.

# A productive way to ask
"NavMesh isn't baking correctly. Check the error log,
then look up this error pattern in the knowledge DB and fix it."
💡 execute_dynamic_script is the universal escape hatch. If no dedicated tool exists (reading a custom component, peeking at internal state with Reflection, etc.), the AI can write and run raw C# right inside the Editor. Just say "run this in C#" and the AI handles the rest.
🛠️

Troubleshooting

The setup snags people hit most often, with the fixes. If you see the same symptom, start here.

T-1

"401 Unauthorized" or "invalid license"

Symptom

When the AI client calls an editor-eye tool, the MCP log returns something like:

HTTP 401 Unauthorized
{ "error": "invalid_license" }

[editor-eye] tool call failed

Cause

The license key in your Authorization: Bearer ... header is one of the following:

  • Partially missing, or has stray whitespace or line breaks
  • From a cancelled or expired license
  • Copied with the literal "Bearer " prefix attached (the prefix belongs on the Authorization line, not inside the key)

Fix

  1. Open your dashboard and re-copy the current license key (click to copy)
  2. Edit the Authorization line in your MCP config (claude_desktop_config.json / ~/.claude/mcp.json / etc.) so it looks like:
    "headers": {
      "Authorization": "Bearer 9b2c-…-fa4d"
    }
  3. Fully quit and relaunch the AI client so it re-reads the MCP config
  4. Re-run the tool — you should now see success

Notes

  • License keys are UUID v4 strings (e.g. 9b2cabc1-3e7f-4d2a-9c10-fa4d…) — no prefix.
  • If your license is cancelled or expired, you can resume it from /upgrade.
  • editor-eye-windows doesn't need a license key (it's a local CLI). 401 errors only come from the editor-eye cloud side.
T-2

"Unity bridge not connected"

Symptom

When the AI calls an editor-eye tool, auth succeeds but you get back "Unity bridge not connected" or "No active Unity session".

Cause

The server (api.editor-eye.app) is receiving the instruction fine, but it doesn't have a WebSocket session to your Unity Editor. Either the Editor isn't running, or you haven't pressed Connect in Settings yet.

Fix

  1. Open the Unity Editor
  2. Go to Window → Editor Eye → Settings
  3. If the license key field is empty, paste your dashboard key, then click SaveConnect
  4. The status indicator at the bottom of the window should turn Connected
  5. Re-run the tool from the AI

Notes

  • Auto-reconnect handles network drops and sleep — you can also tell the AI "reconnect to Unity" for an instant recovery.
  • Running two Unity Editors with the same license at once is a known caveat: the newer Editor disconnects the older one.
  • Any server-side outages are announced in the latest release notes entry.