,/(/. *(/,
*/(((((/. *((((((*.
.*((((((((((/. *((((((((((/.
./((((((((((((((/ *((((((((((((((/,
,/(((((((((((((/*. */(((((((((((((/*.
,%%#((/((((((* ,/(((((/(#&@@(
,%%##%%##((((((/*. ,/((((/(#&@@@@@@(
,%%######%%##((/(((/*. .*/(((//(%@@@@@@@@@@@(
,%%####%#(%%#%%##((/((((((((//#&@@@@@@&@@@@@@@@(
,%%####%( /#%#%%%##(//(#@@@@@@@%, #@@@@@@@(
,%%####%( *#%###%@@@@@@( #@@@@@@@(
,%%####%( #%#%@@@@, #@@@@@@@(
,%%##%%%( #%#%@@@@, #@@@@@@@(
,%%%#* #%#%@@@@, *%@@@(
., ,/##*. #%#%@@@@, ./&@#* *`
,/#%#####%%#/, #%#%@@@@, ,/&@@@@@@@@@&\.
`*#########%%%%###%@@@@@@@@@@@@@@@@@@&*´
`*%%###########%@@@@@@@@@@@@@@&*´
`*%%%######%@@@@@@@@@@&*´
`*#%%##%@@@@@&*´
`*%#%@&*´
███╗ ███╗ ██████╗██████╗ ██╗ ██╗███╗ ██╗██╗████████╗██╗ ██╗
████╗ ████║██╔════╝██╔══██╗ ██║ ██║████╗ ██║██║╚══██╔══╝╚██╗ ██╔╝
██╔████╔██║██║ ██████╔╝ ██║ ██║██╔██╗ ██║██║ ██║ ╚████╔╝
██║╚██╔╝██║██║ ██╔═══╝ ██║ ██║██║╚██╗██║██║ ██║ ╚██╔╝
██║ ╚═╝ ██║╚██████╗██║ ╚██████╔╝██║ ╚████║██║ ██║ ██║
╚═╝ ╚═╝ ╚═════╝╚═╝ ╚═════╝ ╚═╝ ╚═══╝╚═╝ ╚═╝ ╚═╝ MCP Unity es una implementación del Protocolo de Contexto de Modelo para el Editor de Unity, que permite a los asistentes de IA interactuar con tus proyectos de Unity. Este paquete proporciona un puente entre Unity y un servidor Node.js que implementa el protocolo MCP, lo que permite que agentes de IA como Claude, Windsurf y Cursor ejecuten operaciones dentro del Editor de Unity.
MCP Unity proporciona integración automática con IDEs similares a VSCode (Visual Studio Code, Cursor, Windsurf) añadiendo la carpeta Unity Library/PackedCache a su espacio de trabajo. Esta función:
Mejora la inteligencia del código para los paquetes de Unity
Permite un mejor autocompletado y mejor información de tipo para los paquetes de Unity
Ayuda a los asistentes de codificación de IA a comprender las dependencias de su proyecto.
Las siguientes herramientas están disponibles para manipular y consultar escenas de Unity y GameObjects a través de MCP:
execute_menu_item : ejecuta elementos del menú de Unity (funciones etiquetadas con el atributo MenuItem)
Ejemplo de mensaje: "Ejecute el elemento de menú 'GameObject/Crear vacío' para crear un nuevo GameObject vacío"
select_gameobject : selecciona objetos de juego en la jerarquía de Unity por ruta o ID de instancia
Ejemplo de mensaje: "Seleccionar el objeto de la cámara principal en mi escena"
update_gameobject : actualiza las propiedades principales de un GameObject (nombre, etiqueta, capa, estado activo/estático) o crea el GameObject si no existe
Ejemplo de mensaje: "Establezca la etiqueta del objeto Jugador en 'Enemigo' y desactívelo"
update_component : actualiza los campos del componente en un GameObject o lo agrega al GameObject si no contiene el componente
Ejemplo de solicitud: "Agregue un componente Rigidbody al objeto Player y establezca su masa en 5"
add_package : instala nuevos paquetes en el Administrador de paquetes de Unity
Ejemplo de mensaje: "Agregar el paquete TextMeshPro a mi proyecto"
run_tests : ejecuta pruebas utilizando Unity Test Runner
Ejemplo de mensaje: "Ejecutar todas las pruebas de EditMode en mi proyecto"
send_console_log : envía un registro de la consola a Unity
Ejemplo de mensaje: "Enviar un registro de la consola al editor de Unity"
add_asset_to_scene : agrega un activo de AssetDatabase a la escena de Unity
Ejemplo de mensaje: "Agrega el prefab Player de mi proyecto a la escena actual"
unity://menu-items : recupera una lista de todos los elementos de menú disponibles en el Editor de Unity para facilitar la herramienta execute_menu_item
Ejemplo de mensaje: "Muéstrame todos los elementos de menú disponibles relacionados con la creación de GameObject"
unity://scenes-hierarchy : recupera una lista de todos los objetos del juego en la jerarquía de escenas actual de Unity
Ejemplo de mensaje: "Muéstrame la estructura jerárquica de las escenas actuales"
unity://gameobject/{id} : recupera información detallada sobre un GameObject específico por ID de instancia o ruta de objeto en la jerarquía de la escena, incluidos todos los componentes del GameObject con sus propiedades y campos serializados
Ejemplo de mensaje: "Obtén información detallada sobre el GameObject del jugador"
unity://logs : recupera una lista de todos los registros de la consola de Unity
Ejemplo de mensaje: "Muéstrame los mensajes de error recientes de la consola de Unity"
unity://packages : recupera información sobre los paquetes instalados y disponibles del Administrador de paquetes de Unity
Ejemplo de mensaje: "Enumerar todos los paquetes instalados actualmente en mi proyecto de Unity"
unity://assets : recupera información sobre los activos en la base de datos de activos de Unity
Ejemplo de solicitud: "Buscar todos los recursos de textura en mi proyecto"
unity://tests/{testMode} : recupera información sobre las pruebas en Unity Test Runner
Ejemplo de solicitud: "Enumerar todas las pruebas disponibles en mi proyecto de Unity"
Related MCP server: MCP For Unity
Unity 2022.3 o posterior: para instalar el servidor
Node.js 18 o posterior: para iniciar el servidor
npm 9 o posterior: para depurar el servidor
La instalación de este servidor MCP Unity es un proceso de varios pasos:
Abra el Administrador de paquetes de Unity (Ventana > Administrador de paquetes)
Haga clic en el botón "+" en la esquina superior izquierda
Seleccione "Agregar paquete desde la URL de git..."
Ingresa: https://github.com/CoderGamester/mcp-unity.git
Haga clic en "Agregar"
Para ejecutar el servidor MCP Unity, necesitará tener Node.js 18 o posterior instalado en su computadora:
Visita la página de descarga de Node.js
Descargue el instalador de Windows (.msi) para la versión LTS (recomendado)
Ejecute el instalador y siga el asistente de instalación.
Verifique la instalación abriendo PowerShell y ejecutando:
node --versionVisita la página de descarga de Node.js
Descargue el instalador de macOS (.pkg) para la versión LTS (recomendado)
Ejecute el instalador y siga el asistente de instalación.
Alternativamente, si tienes Homebrew instalado, puedes ejecutar:
brew install node@18Verifique la instalación abriendo la Terminal y ejecutando:
node --versionAbra el Editor de Unity
Vaya a Herramientas > MCP Unity > Ventana del servidor
Haga clic en el botón "Configurar" para su cliente AI LLM como se muestra en la imagen a continuación.
Confirme la instalación de la configuración con la ventana emergente que aparece
Abra el archivo de configuración MCP de su cliente AI (por ejemplo, claude_desktop_config.json en Claude Desktop) y copie el siguiente texto:
Reemplace
ABSOLUTE/PATH/TOcon la ruta absoluta a su instalación de MCP Unity o simplemente copie el texto desde la ventana del servidor MCP del editor de Unity (Herramientas > MCP Unity > Ventana del servidor).
{
"mcpServers": {
"mcp-unity": {
"command": "node",
"args": [
"ABSOLUTE/PATH/TO/mcp-unity/Server~/build/index.js"
]
}
}
}Abra el Editor de Unity
Vaya a Herramientas > MCP Unity > Ventana del servidor
Haga clic en "Iniciar servidor" para iniciar el servidor WebSocket
Abra Claude Desktop o su IDE de codificación de IA (por ejemplo, Cursor IDE, Windsurf IDE, etc.) y comience a ejecutar las herramientas de Unity
Cuando el cliente de IA se conecta al servidor WebSocket, se mostrará automáticamente en el cuadro verde de la ventana.
De forma predeterminada, el servidor WebSocket se ejecuta en el puerto 8090. Puede cambiar este puerto de dos maneras:
Abra el Editor de Unity
Vaya a Herramientas > MCP Unity > Ventana del servidor
Cambie el valor de "Puerto WebSocket" al número de puerto deseado
Unity configurará la variable de entorno del sistema UNITY_PORT en el nuevo número de puerto
Reiniciar el servidor Node.js
Haga clic nuevamente en "Iniciar servidor" para volver a conectar el socket web del Editor de Unity al servidor MCP de Node.js
Establezca la variable de entorno UNITY_PORT en la terminal
Powershell GXP6
Símbolo del sistema/Terminal GXP7
Reiniciar el servidor Node.js
Haga clic nuevamente en "Iniciar servidor" para volver a conectar el socket web del Editor de Unity al servidor MCP de Node.js
De forma predeterminada, el tiempo de espera entre el servidor MCP y el WebSocket es de 10 segundos. Puede modificarlo según el sistema operativo que utilice:
Abra el Editor de Unity
Vaya a Herramientas > MCP Unity > Ventana del servidor
Cambie el valor de "Tiempo de espera de solicitud (segundos)" a los segundos de tiempo de espera deseados.
Unity configurará la variable de entorno del sistema UNITY_REQUEST_TIMEOUT con el nuevo valor de tiempo de espera
Reiniciar el servidor Node.js
Haga clic nuevamente en "Iniciar servidor" para volver a conectar el socket web del Editor de Unity al servidor MCP de Node.js
Para sistemas operativos que no sean Windows, deberá configurar dos lugares:
Abra el Editor de Unity
Vaya a Herramientas > MCP Unity > Ventana del servidor
Cambie el valor de "Tiempo de espera de solicitud (segundos)" a los segundos de tiempo de espera deseados.
Establezca la variable de entorno UNITY_REQUEST_TIMEOUT en la terminal
Powershell GXP8
Símbolo del sistema/Terminal GXP9
Reiniciar el servidor Node.js
Haga clic nuevamente en "Iniciar servidor" para volver a conectar el socket web del Editor de Unity al servidor MCP de Node.js
[!CONSEJO]
El tiempo de espera entre su IDE de codificación de IA (por ejemplo, Claude Desktop, Cursor IDE, Windsurf IDE) y el servidor MCP depende del IDE.
El servidor MCP Unity se compila con Node.js. Requiere compilar el código TypeScript a JavaScript en el directorio build . Para compilar el servidor, abra una terminal y:
Navegue hasta el directorio del servidor:
cd ABSOLUTE/PATH/TO/mcp-unity/Server~Instalar dependencias:
npm installConstruir el servidor:
npm run buildEjecutar el servidor:
node build/index.jsDepure el servidor con @modelcontextprotocol/inspector :
PowerShell
npx @modelcontextprotocol/inspector node Server~/build/index.jsSímbolo del sistema/Terminal
npx @modelcontextprotocol/inspector node Server~/build/index.jsNo olvide apagar el servidor con Ctrl + C antes de cerrar la terminal o depurarlo con el Inspector MCP .
Habilite el inicio de sesión en su terminal o en un archivo log.txt:
Powershell GXP16
Símbolo del sistema/Terminal GXP17
Asegúrese de que el servidor WebSocket esté ejecutándose (verifique la ventana del servidor en Unity)
Envíe un mensaje de registro de consola desde el cliente MCP para forzar una reconexión entre el cliente MCP y el servidor Unity
Cambie el número de puerto en la ventana Servidor MCP del Editor de Unity. (Herramientas > MCP Unity > Ventana Servidor)
Comprueba si hay mensajes de error en la consola de Unity
Asegúrese de que Node.js esté correctamente instalado y accesible en su PATH
Verifique que todas las dependencias estén instaladas en el directorio del servidor
La herramienta run_tests devuelve la siguiente respuesta:
Error:
Connection failed: Unknown errorEste error se produce porque la conexión del puente se pierde cuando el dominio se recarga al cambiar al modo de reproducción.
La solución alternativa es desactivar Recargar dominio en Editar > Configuración del proyecto > Editor > "Ingresar a la configuración del modo de reproducción" .
Si tiene alguna pregunta o necesita ayuda, abra un problema en este repositorio.
Alternativamente, puede comunicarse con nosotros en:
Linkedin:
Discord: gamester7178
Correo electrónico: game.gamester@gmail.com
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios o abrir un problema con su solicitud.
Confirme sus cambios siguiendo el formato de confirmaciones convencionales .
Este proyecto está bajo licencia MIT
Sends a message to the Unity console
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to display in the Unity console | |
| type | No | The type of message (info, warning, error) |
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 what the tool does without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, if it requires specific permissions, how messages appear in the console, or any rate limits. The description is minimal and lacks necessary context for a mutation tool.
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 with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 that sends messages (implying mutation) with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after sending, return values, error conditions, or integration with Unity's console system. The minimal description leaves significant gaps in understanding the tool's behavior.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaning beyond what the schema provides about message content or type options. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('sends') and target ('message to the Unity console'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'execute_menu_item' or 'run_tests', which prevents a perfect score.
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 logging to files or using other console methods. It lacks context about appropriate scenarios or exclusions, offering only basic functional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manages packages in the Unity Package Manager
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | The branch to use for GitHub packages (optional) | |
| methodSource | Yes | The method source to use (registry, github, or disk) to add the package | |
| packageName | No | The package name to add from Unity registry (e.g. com.unity.textmeshpro) | |
| path | No | The path to use (folder path for disk method or subfolder for GitHub) | |
| repositoryUrl | No | The GitHub repository URL (e.g. https://github.com/username/repo.git) | |
| version | No | The version to use for registry packages (optional) |
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 but only states a general purpose. It doesn't describe whether this tool performs read-only or destructive operations, what permissions are needed, how it handles errors, or what the typical output looks like, which is insufficient for a tool with multiple parameters and no output schema.
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 with no wasted words, making it appropriately concise. However, it lacks front-loaded detail that could immediately clarify the tool's specific actions, slightly reducing its effectiveness despite the brevity.
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 with 6 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what the tool does beyond a vague purpose, leaving gaps in understanding behavioral traits, return values, and proper usage context, which is inadequate for effective agent invocation.
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 100%, so all parameters are documented in the schema itself. The description adds no additional meaning about parameters beyond the general purpose, resulting in a baseline score of 3 where the schema does the heavy lifting without enhancement from the description.
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 'Manages packages in the Unity Package Manager' states a general purpose but is vague about what specific actions are performed. It doesn't specify whether it adds, removes, updates, or lists packages, and doesn't distinguish from sibling tools like 'execute_menu_item' or 'run_tests' which are unrelated to package management.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for package management, or exclusions, leaving the agent to infer usage from the parameters alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs Unity's Test Runner tests
| Name | Required | Description | Default |
|---|---|---|---|
| testFilter | No | Optional test filter (e.g. specific test name or namespace) | |
| testMode | No | The test mode to run (EditMode, PlayMode, or All) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only or destructive operation, execution time, error handling, or output format (e.g., test results). The phrase 'Runs' implies execution but gives no further context on safety or side effects.
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 with no wasted words, making it easy to parse. It's front-loaded with the core action and resource, earning full marks for conciseness and structure.
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 complexity of running tests (which involves execution and potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't explain what happens during execution, what results to expect, or any constraints, leaving significant gaps for an agent to use the tool effectively.
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 100% description coverage, documenting both parameters clearly. The description adds no additional meaning beyond what the schema provides, such as examples of test filters or implications of test modes. With high schema coverage, the baseline score of 3 is appropriate.
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 ('Runs') and the resource ('Unity's Test Runner tests'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'execute_menu_item' or 'package_manager', which could also involve Unity operations, so it doesn't reach the highest score.
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. There's no mention of prerequisites, context (e.g., when in Unity's workflow), or comparisons to siblings like 'execute_menu_item' for other Unity actions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sets the selected object in the Unity editor by path or ID
| Name | Required | Description | Default |
|---|---|---|---|
| objectPath | Yes | The path or ID of the object to select (e.g. "Main Camera" or a Unity object ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Sets the selected object' which implies a mutation (changing editor state), but doesn't disclose critical traits like whether this requires specific editor modes, if changes are undoable, potential side effects, or error handling. For a mutation tool with zero annotation coverage, this is a significant gap.
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 action ('Sets the selected object') with essential details ('in the Unity editor by path or ID'). Every word earns its place with no redundancy or fluff, making it highly concise and well-structured.
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 (a mutation in an editor environment), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or return values, leaving gaps for an AI agent to understand how to invoke it correctly in context.
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 100% description coverage, with the parameter 'objectPath' fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'path or ID' and providing an example ('Main Camera'), but doesn't elaborate on syntax, format differences, or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Sets the selected object') and the resource ('in the Unity editor'), with the method ('by path or ID') specified. It distinguishes from siblings like 'execute_menu_item' or 'run_tests' by focusing on object selection. However, it doesn't explicitly differentiate from all siblings (e.g., 'notify_message' is clearly different, but the distinction could be more explicit for a perfect score).
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 open Unity project), exclusions, or comparisons to sibling tools. Usage is implied through the action but lacks explicit context for selection.
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.
v1.0.0execute_menu_itemnotify_messagepackage_managerrun_testsselect_objectScored across 5 tools
Each tool has a clearly distinct purpose targeting different Unity Editor functionalities: executing menu items, sending console messages, managing packages, running tests, and selecting objects. There is no overlap or ambiguity in their intended uses.
The tool names follow a consistent snake_case pattern with descriptive verb_noun combinations (e.g., execute_menu_item, notify_message). However, 'package_manager' deviates slightly by using a noun-only name instead of a verb_noun structure, but overall the naming is highly readable and predictable.
With 5 tools, the server is well-scoped for its purpose of interacting with the Unity Editor. Each tool serves a specific, essential function, and there are no extraneous or redundant tools, making the count appropriate for the domain.
The toolset covers key Unity Editor operations like executing commands, messaging, package management, testing, and object selection. However, there are notable gaps for a full editor integration, such as creating or modifying assets, building projects, or accessing scene hierarchies, which limits comprehensive workflow coverage.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
