How the built-in Studio AI assistant plans, uses tools, and keeps changes reviewable.

Studio Copilot Overview

Studio Copilot is the built-in AI assistant for ED5 MMO Studio. It understands the engine, the editor, and your project data, then uses real tools to help you build.

Where It Appears

Studio Copilot can appear in:

Studio Web.
The Admin editor.
The desktop Studio app.
External MCP clients through Creator MCP.

What Makes It Different

Generic AI can describe a game idea. Studio Copilot can operate the Studio tool layer.

It can:

Search and read your project records.
Create and update structured game content.
Generate assets and link them to entities.
Validate content after changes.
Run playtest simulations for selected scenarios.
Remember project-specific style and lore notes.

What Context It Uses

Studio Copilot is designed to be both engine-aware and project-aware.

Depending on the task, it can ground itself with:

Engine docs and schema knowledge.
Your current project records such as items, quests, mobs, NPCs, zones, and media.
The page or editor surface you are currently on.
Prior thread context and project memory such as style rules, lore, naming conventions, or banned content.
Validation feedback from previous runs.

The goal is not just to answer from model memory, but to act from current project truth.

The Run Flow

Most requests follow this flow:

You give a goal.
The assistant gathers context from your current project.
It plans tool-backed steps.
Risky work is gated by approval or your autopilot policy.
Tools run through the gateway.
Results, IDs, artifacts, and validation summaries are returned.

In practice, a strong run usually looks like this:

1. You describe the outcome you want. 2. Copilot inspects the relevant records, screen context, or docs. 3. It proposes a short plan. 4. You approve the writes, or let autopilot continue within your rules. 5. Copilot creates or updates records, imports assets, or runs validations. 6. It closes with concrete proof: what changed, what was created, what validation passed, and what still needs review.

What A Good Result Looks Like

A useful Studio Copilot answer should not end at vague prose. It should leave you with evidence.

Typical run outputs include:

Record names, IDs, or linked entities that were created.
A summary of fields that changed.
Imported asset names or generated media candidates.
Validation results or playtest findings.
Follow-up options for iteration.

If a run changes nothing, the assistant should still tell you why: missing permission, invalid target, model/provider issue, or a validation failure.

Risk Classes

Risk	Meaning
R0	Read-only: search, inspect, explain, validate
R1	Reversible write: create content, update fields, import draft assets
R2	Harder-to-reverse project change: large edits, event materialization, deletes
R3	Destructive or platform-level operation: not exposed through public Creator MCP

For the operating model around approvals and autopilot, see Approvals, Autopilot & Safety.

Public Versus Internal AI Tools

Creator tools are user-facing and project-scoped. Platform tools are internal and used by ED5 developers for testing, admin, database checks, and deployment validation.

External clients such as Claude only receive the Creator MCP tool list.

Best-Fit Tasks For Copilot

Studio Copilot is strongest when the task has a clear target and can be checked afterward. Good examples:

Draft a new item family from an existing biome or faction theme.
Review an NPC dialogue tree for missing branches or reward links.
Create a starter quest chain and validate the NPC references.
Generate item icon variants and link the chosen one.
Inspect a zone and report missing spawn, objective, or loot coverage.
Summarize how a system works using your current project as examples.

Less effective prompts are broad and underconstrained, such as "make my whole game better" without naming the area, audience, or success criteria.

Building a Game From a Description

Type /build and describe the game you want. The assistant asks one round of questions if it needs to, then produces a build plan: ordered phases, and inside each phase a list of tasks it can carry out one at a time.

Nothing is created yet. The plan card shows you, per task:

Shown	What it tells you
Task name and goal	The single instruction one run will carry out
Tool chips	The exact actions the task expects to take, by name
Risk badge	The highest risk class among those actions
"Asks again"	The task contains something hard to reverse, so it will stop for a second confirmation even after you approve the plan
Cost	An estimate for that task, priced from the model you have selected

Use the ✕ on any task to skip it before you start. When you are happy, press Approve & build. The assistant then works task by task, showing progress and what it spent as it goes. You can stop at any point and resume later — finished tasks are not repeated.

Undoing What the Assistant Did

Every change the assistant makes is recorded with the exact state it replaced, so you can put it back.

Type /undo to roll back the most recent run in the conversation, or /undo <run id> for a specific one.
Or open a finished turn in the chat and choose Undo run.
Choose Pick changes instead to select individual changes and undo only those.

Undo always shows you what it will restore and waits for your confirmation. It covers everything the assistant can change:

What it changed	What comes back
A record it created	The record is removed
A record it edited or deleted	The record as it was, field for field
Painted terrain, biomes or tile attributes	The affected map chunks exactly as they were
An object placed, removed or moved	The map chunks at both ends of the change
An NPC, mob or resource placement	The placement and its spawn rules
An event script	The event's previous script
A whole map it deleted	The map, its terrain, its events and its spawn rules
An image it imported or linked	The record points back at the image it had before

Two things to know. Undoing an image change re-points the record — the image file itself is never deleted from your media library, because other records may be using it. And the undo is itself recorded, so if you change your mind you can open the undo turn and press Redo run.

If a change could not be captured (for example the editor was unreachable at the moment it happened), undo says so and leaves that change alone rather than pretending it was rolled back.

Project Memory

Project memory is where Copilot stores durable context that should outlive a single chat run.

Useful memory examples include:

World lore and canon rules.
Naming patterns for factions, towns, or items.
Art direction notes.
Balance rules such as rarity targets or low-level stat ceilings.
Content that must be avoided.

Use project memory for stable rules. Use the chat thread for one-off tasks.

In-App Copilot Versus Creator MCP

Use the built-in copilot when you want the assistant anchored to the page you are actively editing.

Use Creator MCP when you want to work from Claude or another external client and still call the same project-safe tool surface.

Both paths are meant to converge on the same core behavior: inspect, plan, ask when needed, act through tools, and return proof.

Privacy Notes

The assistant should send only the context needed for the current task to model providers. API keys are verified server-side and are not exposed to browser JavaScript after creation.

Review generated content before shipping your live game.

Next: Approvals, Autopilot & Safety and Providers & AI Credits.

Creator MCP & Claude Setup Approvals, Autopilot & Safety