This server allows you to manage and interact with Unity projects and their files. You can:
List all available Unity projects
List all files within a specific Unity project
Read the content of a specific file inside a Unity project
Offers a containerized deployment option that communicates with Unity over the network.
Provides an NPX package deployment option for installing and running the MCP server.
Enables AI assistants to interact with Unity game environments, allowing for code execution, game object inspection, scene analysis, testing, and runtime debugging and modification of game state.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Unity-MCP list all game objects in the current scene"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A bridge between Unity and AI assistants using the Model Context Protocol (MCP).
Unity-MCP is an open-source implementation of the Model Context Protocol for Unity game development. It enables AI assistants to interact with Unity game environments through a standardized interface, allowing for AI-assisted game development, automated testing, scene analysis, and runtime debugging.
The architecture has been simplified to use AILogger for persistence, removing the need for a separate server component:
AI Assistant <-> Unity-MCP STDIO Client <-> Unity Client <-> AILoggerAI Assistant: Communicates with the Unity-MCP STDIO Client using the MCP protocol
Unity-MCP STDIO Client: Forwards commands to the Unity Client and stores results in AILogger
Unity Client: Executes commands in Unity and returns results
AILogger: Stores logs and results for later retrieval
The Unity-MCP STDIO Client communicates directly with the Unity Client, which provides endpoints for both code execution and queries. The query tool transforms queries into code execution by wrapping them in a return statement.
Related MCP server: Advanced Unity MCP
Execute C# code in the Unity runtime environment
Inspect game objects and their components
Analyze scene hierarchies and structures
Run tests and receive results
Invoke methods on game objects and components
Modify game state during runtime
Unity Editor Extension: An Editor extension that persists beyond game execution cycles
Docker Container: A containerized version that communicates with Unity over the network
NPX Package: A Node.js package that can be installed and run via NPX
MCP Architecture: Overview of the MCP architecture and namespaces
MCP STDIO Client: Information about the MCP STDIO client and its logging capabilities
Query Tool: Detailed information about the query tool and how it works
AILogger Integration: Detailed information about the AILogger integration
API Reference: Detailed information about the API endpoints
Installation Guide: Step-by-step instructions for installing and setting up Unity-MCP
Development Guide: Information about the development environment and workflow
Hot Reloading Guide: Detailed information about hot reloading in the development environment
Hot Reloading Quick Reference: Quick reference guide for hot reloading commands and tips
Contributing Guide: Guidelines for contributing to the project
To get started with Unity-MCP, follow these steps:
Clone the repository:
git clone https://github.com/TSavo/Unity-MCP.git
cd Unity-MCPInstall dependencies:
npm installBuild the project:
npm run buildStart the MCP STDIO client:
npm startThis will start the MCP STDIO client that communicates with Unity and uses AILogger for persistence.
Note: Make sure AILogger is running on http://localhost:3030 or set the AI_LOGGER_URL environment variable to point to your AILogger instance.
Run tests:
# Run all tests
npm test
# Run only unit tests
npm run test:unit
# Run only e2e tests
npm run test:e2e
# Run tests with a specific pattern
npm test -- --testNamePattern="should return the server manifest"
npm run test:unit -- --testNamePattern="should return the server manifest"
npm run test:e2e -- --testNamePattern="should discover the test server"For more detailed instructions, see the Installation Guide.
To connect the Unity-MCP bridge to an AI assistant, you need to create an MCP configuration file:
{
"mcpServers": {
"unity-ai-bridge": {
"url": "http://localhost:8080/sse"
}
}
}Place this file in the appropriate location for your AI assistant. For Claude, this would typically be in the Claude Desktop app's configuration directory.
The Unity-MCP bridge provides the following tools:
execute_code: Execute C# code directly in Unity.
query: Execute a query using dot notation to access objects, properties, and methods.
get_logs: Retrieve logs from AILogger.
get_log_by_name: Retrieve a specific log from AILogger.
You can execute C# code in Unity using the execute_code tool. The code will be executed in the Unity runtime environment, and the result will be stored in AILogger for later retrieval.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "execute_code",
"arguments": {
"code": "Debug.Log(\"Hello from Unity!\"); return GameObject.FindObjectsOfType<GameObject>().Length;",
"timeout": 5000
}
}
}{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "{\"status\":\"success\",\"logName\":\"unity-execute-1712534400000\",\"result\":{\"success\":true,\"result\":42,\"logs\":[\"Hello from Unity!\"],\"executionTime\":123}}"
}
]
}
}You can query Unity objects using the query tool. This allows you to access objects, properties, and methods using dot notation.
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "query",
"arguments": {
"query": "Camera.main.transform.position",
"timeout": 5000
}
}
}{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [
{
"type": "text",
"text": "{\"status\":\"success\",\"logName\":\"unity-query-1712534400000\",\"result\":{\"success\":true,\"result\":{\"x\":0,\"y\":1,\"z\":-10},\"executionTime\":45}}"
}
]
}
}You can retrieve the results of previous operations from AILogger using the get_log_by_name tool.
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "get_log_by_name",
"arguments": {
"log_name": "unity-execute-1712534400000",
"limit": 1
}
}
}{
"jsonrpc": "2.0",
"id": 3,
"result": {
"content": [
{
"type": "text",
"text": "{\"status\":\"success\",\"name\":\"unity-execute-1712534400000\",\"entries\":[{\"id\":\"123e4567-e89b-12d3-a456-426614174000\",\"name\":\"unity-execute-1712534400000\",\"data\":{\"result\":{\"success\":true,\"result\":42,\"logs\":[\"Hello from Unity!\"],\"executionTime\":123},\"timestamp\":\"2025-04-08T00:00:00.000Z\"},\"timestamp\":\"2025-04-08T00:00:00.000Z\"}]}"
}
]
}
}Once the AI assistant has access to the Unity tool, you can ask it to perform tasks like:
Can you execute the following C# code in Unity?
GameObject.Find("Player").transform.position = new Vector3(0, 1, 0);MIT
T Savo (@TSavo)
Lists all the files inside a Unity project.
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Lists') but doesn't describe key traits like whether it's read-only (implied but not explicit), what format the output takes (e.g., list of filenames vs. metadata), pagination, error conditions, or permissions required. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple listing tool and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on parameter semantics, output format, and behavioral context (e.g., read-only nature, error handling). While concise, it doesn't provide enough information for an agent to use the tool effectively without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the parameter 'projectName' is undocumented in the schema. The description adds no information about this parameter—it doesn't explain what 'projectName' refers to (e.g., a Unity project identifier), valid formats, or examples. With low schema coverage, the description fails to compensate, leaving the parameter's meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('all the files inside a Unity project'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_projects' (which lists projects) or 'read_file' (which reads file contents), missing the opportunity to clarify its specific scope within the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to siblings like 'list_projects' for project-level listing or 'read_file' for accessing file details. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available Unity projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether results are paginated, sorted, filtered, or include metadata; whether it requires authentication; or what the return format looks like. This leaves significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a simple list operation with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'lists' entails (e.g., format, metadata included) or behavioral aspects, leaving the agent with insufficient context to understand the tool's full behavior beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, earning a baseline high score since it doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('all available Unity projects'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_files_in_project' or 'read_file', which would require mentioning it returns project-level metadata rather than file contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that 'list_files_in_project' is for files within a specific project or 'read_file' is for file contents, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the contents of a file inside a Unity project.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Reads') but doesn't mention potential constraints like file size limits, encoding issues, error handling for missing files, or performance implications. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the core action and context efficiently, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (reading file contents), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., text content, binary data, error messages) or address common edge cases like permissions or file existence, making it inadequate for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It implies the 'path' parameter refers to a file path within a Unity project, adding context beyond the schema's minimal type constraints. However, it doesn't specify path format (e.g., relative vs. absolute), supported file types, or examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reads') and target ('contents of a file inside a Unity project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_files_in_project' (which enumerates files vs. reading content), leaving room for minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_files_in_project' or 'list_projects'. It mentions the context ('inside a Unity project') but lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0list_files_in_projectlist_projectsread_fileEach tool has a clearly distinct purpose: list_projects enumerates projects, list_files_in_project enumerates files within a project, and read_file retrieves file contents. There is no overlap or ambiguity in their functions, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern (list_projects, list_files_in_project, read_file) with clear, descriptive verbs. The naming is uniform and predictable, enhancing usability and reducing confusion.
With only 3 tools, the set feels thin for a Unity project management server, as it lacks essential operations like creating, updating, or deleting files or projects. While the tools are well-defined, the count is borderline low for the apparent scope.
The tool surface is significantly incomplete for Unity project management. It covers listing and reading but lacks any write, update, or delete operations (e.g., create_project, write_file, delete_file), which are critical for full lifecycle coverage and will likely cause agent failures in many workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Savecraft serves real save game data and expert game knowledge to AI assistants.
Live browser debugging for AI assistants — DOM, console, network via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TSavo/Unity-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
