Request for Official Support and Ecosystem for External AI Tools

Unity Engine
, , ,
1

Hi everyone,

Recently, many people are using AI-based tools such as Cursor, Antigravity (Windsurf), and GitHub Copilot. Even terminal-based agents like Claude Code are becoming surprisingly useful.

While we can technically use them right now, the integration still feels a bit “unofficial” and hacky. I think Unity could unlock so much potential by officially supporting these external ecosystems.

Here are a few things I’d love to see in the future:

  1. Broader support for VSCode-based IDE & CLI Tools: Currently, setting up AI-specific IDEs (which are often VSCode forks) or CLI agents requires some workarounds. It would be great if Unity officially recognized these modern tools as first-class citizens, ensuring plugins and file interactions work smoothly without breaking.

  2. Seamless C# & Debugging in AI IDEs: Using “Attach to Unity” or getting proper IntelliSense in tools like Cursor can be hit-or-miss due to licensing or compatibility issues. We really need an official way to debug and write code in these environments without relying on unstable 3rd-party extensions.

  3. Official MCP (Model Context Protocol) Support: This is a big one. AI agents should be able to safely read project settings (tags/layers/player settings/graphics settings, etc.) and even modify scenes/prefabs via API, and should be able to reflect the context of this project when writing and modifying scripts. This would prevent the AI from hallucinating or breaking file structures. Currently, this relies on user-created MCPs.

  4. Direct Console Access for AI: Copy-pasting error logs to an AI is tedious. It would be amazing if external AI tools could “hook” into the Editor Console to read compile errors or runtime exceptions in real-time and suggest fixes automatically. This could be implemented in the mcp above.

  5. Unity-Specific Agent Profiles: Generic AI agents often treat Unity projects like standard console apps (trying to run dotnet run, etc.). An official “Unity Profile” definition would help these agents understand Assembly Definitions and the proper build pipeline right out of the box.

One last thought: I know Unity is working hard on internal AI tools, which is great. But personally, I really hope Unity prioritizes becoming an “AI-Ready Platform” for the tools we already use and love.

3 Likes
AI/LLM/MCP support in Unity (native integration with VS Code/Visual Studio Copilot / Cursor / Antigravity)
2

That’s the IDE’s job, not Unity’s.

Rider and Claude/Junie work well together for Unity. This includes compiling a Unity project in the IDE and “reading” the error logs.

That’s just plain and simple lack of IDE support. You get exceptional Unity integration with Rider (including asmdefs) but other IDEs are lacking.

1 Like
3

Thinking that tool integration should solely be the responsibility of the IDE or tool developers is an oversimplification. This integration isn’t just the IDE’s job; it requires active collaboration between Unity and the IDE providers.

Rider, which you mentioned, is a prime example of this collaboration. Unity provides an official package via the Package Manager, and Rider natively detects and integrates with the Unity project. it wasn’t a Jetbrains-only effort, and of course it was a collaboration with Unity.

And if you modify scripts using Claude Code, the Gemini CLI, or other AI agents, you currently need MCP to read errors from the Unity Editor console. And that solution is still unofficial.

It’s clear that Unity needs to work with AI tools to prepare for the growing use of AI tools in the future.

This isn’t simply a matter of inadequate IDE support; I’m calling for official support from Unity, just as I did with Rider. I am arguing that Unity needs to provide support so that agents can truly understand the unique nature and context of a Unity project.

I’ve been using Rider as a subscriber for several years, and I’ve also tried Junie. I’m well aware that Rider boasts Unity integration, including features like generating/editing asmdefs and inspecting layers, tags, and files in the Resources folder. However, as I mentioned earlier, this wasn’t solely a Rider effort; it was a collaborative effort with Unity.

When I talk about support for AI tools, I’m not limiting the discussion to AI-centric IDEs like Cursor or Antigravity, but referring to the broader usage of AI agents and tools. The dotnet run issue I mentioned earlier is a problem that persists even when using agents like GitHub Copilot or Gemini Code Assistant within Rider.

Sure, agents can handle basic code generation, but it is all too common for them to fail to grasp the specific nuances of a Unity project when tasked with more complex, deep-dive operations.

You probably love Rider and enjoy using Junie, but there are countless AI tools out there, and everyone has their own preferences. There needs to be support for these tools, including official interfaces.

4

latest AI beta actually has lots of nice features,

but the quality is not that great.. also would be probably much cheaper to use external models.

5

Unity is collaborating with Microsoft in the same way. Though you have to consider that for Microsoft, Unity is but a small part of their ecosystem.

The integration really is 95% on the IDE developer’s side. I’m certain Unity doesn’t do much in that respect other than communications and the occassional “okay we’ll expose that method/property for you in the next update”.

Last time I checked Rider can read Unity’s console. But what I meant was the build process output, that’s definitely available.

See and that’s where you’re lobsided - they don’t support Jetbrains but not support Microsoft. It’s Microsoft - for decades now - that has seemingly deprioritized game engine integrations. I don’t think they get offered any less support than Jetbrains.

Personally I think they sit on such a huge chunk of legacy code that they’ll started over Visual Studio, released it under a slightly new name and as open source, because it was the only viable option going forward to do a complete rewrite of VS.

Microsoft could do as much or more than Jetbrains, except they choose not to.

I agree with you on having better AI integration in Unity, respectively ways to “connect” AI with Unity. However given that Unity is building their own AI solution, they won’t like to open that can for everyone … is what I’m thinking. So I wouldn’t be on an official “open ports” initiative by Unity, to the contrary.

And yes, the more IDE support the better. But any of these new IDEs can, if they choose to, right now support Unity. They just need to look at the Rider/VS packages and figure out how to make this work for them. No problemo.

However they have bigger issues to solve, not the least figuring out who’s going to win that race. So once one ore two of those new IDEs catch on and become big, that’s when you can expect them to integrate into engines. No earlier, unless it’s a heavily game engine focused IDE.

1 Like
6

Yes! I strongly believe Unity would greatly benefit from implementing official MCP (Model Context Protocol) support. It would provide real value to developers and would be a meaningful innovation for the Unity ecosystem.

I have tested several third-party MCP solutions for Unity. Unfortunately, they all come with significant drawbacks: incomplete/immature tooling, rough edges, and code quality issues that make them hard to rely on in production workflows. Having an official, first-party MCP implementation with high-quality, well-designed tools would be much more practical and trustworthy.

One concrete example: I would like to configure FBX import settings via MCP. Ideally, I could provide an LLM/AI agent with a simple list of animation clips and frame ranges, and the agent would apply the correct clip definitions and related import settings automatically. This type of workflow would save substantial time and reduce human error, but it requires robust, officially supported MCP tools in Unity (e.g., FBX/ModelImporter control, validation, safe change application, and clear logging).

2 Likes
7

If we were merely talking about providing simple context like we’ve seen in the past—such as reading project tags and layers, scanning files in the Resources folder, or having pre-made Unity script templates—then you would be right.

But is that really sufficient context for modern AI tools? Absolutely not. You are still viewing IDE usage through the lens of traditional workflows.

Going forward, developers will leverage a multitude of AI tools for game development. For these tools to function effectively within Unity, they require deep, specific context regarding the project structure. Providing this via MCP (Model Context Protocol) or other standard interfaces is essential for this workflow. My point is that I want this to happen under Unity’s official support, rather than relying on unofficial user-created workarounds as we do now.

Did Microsoft neglect Unity? No, Microsoft and Unity have collaborated closely for a long time. Sure, VS or VSCode might have offered slightly less integration than Rider, but let’s not forget that VS has historically been free while Rider is a paid product(not now). That difference is to be expected. Furthermore, I’m not talking solely about IDE support here.

While Unity is indeed developing its own AI technologies as you mentioned, I find it hard to believe they will adopt a closed-door policy. As seen in this thread (https://discussions.unity.com/t/support-for-cursor-ai-ide/1635253/10), Unity is evidently keeping support for third-party AI-based IDEs in mind.

Also, Unity doesn’t need to sit back and wait to see which product wins the race. If they establish MCP and common interfaces, it becomes the IDE developers’ job to utilize them. The problem I’m raising is simply that these standards don’t exist yet.

8

I totally agree. I think official MCP support should be the top priority for AI integration. There are countless tools being released right now, but having an official MCP would allow us to use them with much more confidence. It would likely lead to a wider variety of tools being created as well.

As you mentioned, handling animations via FBX import settings in Unity is a real pain. If something like MCP could allow us to read and edit that FBX context, it would speed up the workflow immensely. We could simply issue a command and get it done. That’s exactly the kind of future I’m hoping for.

1 Like
9

just to pick on this,
i don’t think that would be possible, for AI to know which frame some action exactly starts and ends?

but for a simple editor script, you can give it a list of frames and it can clip your animation into clips and apply required settings. (thats what i’m usually doing for complex anims)

just for reference: in the latest unity AI Beta there are new features again:

10

I agree. That’s definitely a challenge right now. We might need to wait until AI agents evolve enough to visually analyze the preview window or interpret per-frame values in animation clips as actual motion.

Like you said, writing custom editor scripts is a solid approach. That’s probably how most of us handle it for the time being. I actually edit .meta files directly sometimes—current AI agents might already be capable of handling this if the task is simple enough.

Also, thanks for bringing up Unity’s new AI features. I’ll definitely need to take a closer look at those soon.

11

In my view, unity.ai.assistant feels like a stillborn start. What Unity really needs is a solid, official integration with MCP. There is no need to reinvent the wheel.

MCP is already used across the majority of the AI tooling market. We don’t need alternative protocols or yet another Unity-specific approach. Visual Studio Copilot works very well with MCP today. I personally tested connecting an “Opus 4.5” model, and it performed especially for analyzing screenshots.

What’s missing is official Unity support for the full MCP workflow and high-quality MCP tools. There are already community-made Unity MCP implementations that work reasonably well, but they are still third-party scripts maintained outside of Unity. I believe Unity can provide a deeper, more reliable level of access to editor/importer functionality through MCP tools (with proper stability, security, and long-term support).

1 Like
12

The AI community is rapidly improving tooling. As Ray Kurzweil has noted, AI tools are exactly what will continue accelerating through 2030. There is no need to reinvent what already exists.

MCP is effectively the core industry standard right now. It enables integration with a wide range of tools. For example:

by connecting ElevenLabs MCP , you can generate voiceovers,
by connecting MCP Hunyuan, you can generate rough 3D models for prototypes,
by connecting MCP Stable Diffusion, you can generate draft textures,
Figma already has its own MCP server, so you can build UI from Figma and bring it directly into Unity.

Elon Musk is even saying he plans to build his own engine to generate games using AI. If this keeps going, I’m afraid I might have to switch to his future engine. I’m joking, of course but, seriously, MCP offers enormous potential.

This is precisely why an official, first-party MCP integration in Unity would be so valuable: it would let Unity developers leverage the broader AI ecosystem through a single standard interface, with reliable, secure, and well-maintained tooling.

1 Like
13

I fully agree.

But Unity so far has been determined to provide their own AI Assistant - though notably the messaging wasn’t anywhere near prominent than 1-2 years ago, so perhaps there are strategic changes happening behind the scenes.

Since efforts happen in the open source, using and supporting the existing open source solutions would be the right way to increase the pressure on Unity.

They inadequately supported Unity for the longest time. Though my viewpoint may be skewed since I hadn’t used VS 2022, I can’t imagine there having been a significant leap up from 2019. In that version, it practically treated a Unity project like any other C# project with minimal integration. I think it still reported “Update() <= method never called” back then.

With the little experiments I ran with it, I have to agree the chat assistant is currently lacking a lot.

Most importantly: it won’t edit scripts directly. It seemed loaded with the cargo cult habits that plague the beginner landscape. It didn’t adhere to Unity’s own recommendations, writing an IMGUI editor window for me rather than using UI Toolkit. And it being part of the editor UI it feels woefully out of place for me - I want my AI in the IDE where I write the code.

14

Trying to keep up by building your own dedicated AI assistants is a losing strategy. Creating your own LLM model and your own “Cursor-like” IDE would likely cost more than the entire value of Unity as a company - and Unity is already a few years behind in this space.

And the bigger question is: why? We already have strong, general-purpose ecosystems and providers: DeepSeek, Anthropic, xAI, ChatGPT, Google Gemini - and many more assistants that can also be run locally. If Unity does not implement the MCP protocol, I believe that in a few years another engine may appear that can do everything Unity can today, but with native MCP capabilities out of the box.

1 Like
15

I just stumbled across Unity AI Gateway and this seems to be exactly what y’all are asking for

4 Likes
16

Has anyone already been granted access to Unity AI Gateway?

If so, could you please share whether it connects reliably to the major AI IDE/tools—Cursor, Windsurf, Antigravity, Claude Code, Visual Studio Code + Copilot, and Visual Studio (Insiders) + Copilot?

Does it work via MCP (Model Context Protocol), or does it require a different integration approach?
Simply put: if Unity AI Gateway requires some different approach instead of MCP, then it’s just reinventing the wheel again.

2 Likes
17

There doesn’t seem to be much information available about the AI ​​Gateway. Based on what’s known, it seems similar to the MCP.

I’ve applied, but I’m not sure when or how the results will be released.

Below is a translated version of an interview with a Unity employee about the AI ​​Gateway:

The Unity AI Gateway, scheduled to be released in 2026, is a solution for developers looking to integrate AI into their workflows. It is expected to become the officially supported way to securely connect third-party AI agents to Unity. The Unity AI Gateway will allow verified third-party agents to interact with the editor, while providing highly accurate support based on deep context, such as the developer’s scene, hierarchy, assets, and platform target.

1 Like
18

I highly doubt that Unity AI Gateway will support Cursor/Antigravity/Claude Code/Windsurf and other AI platforms. MCP, on the other hand, is an international standard.

2 Likes
19

Hi everyone,

Thank you for this detailed thread! It’s clear that many of you are already pushing the boundaries of what’s possible by connecting external agents to Unity already with MCP. I get it, you want Unity to work with the tools you already use.

The sign up form mentioned above is for our AI Gateway tool that was mentioned very briefly in the keynote at Unite 2025. The gateway exists to connect 3rd party agents to the Editor securely, and also connect it with our context tools that can extract project data and make it easier for machines to comprehend/learn.

We hear you and agree that MCP is the industry standard for agentic workflows, and the AI Gateway is made possible via MCP. It’s also built on our core standards, so that you get a secure and authenticated environment with managed permissions to protect project data.

If you’re at all interested in the new tool, I recommend you sign up on the form because we’re going to be scaling up access, and that form is how we’ll send invites in the next few weeks/month.

–

I also wanted to mention the difference between the AI Gateway signup and the Unity AI Beta Signup (closed trials of the new Unity AI). Unity AI consists of 2 tools: Assistant and Generators, and Points are required to generate with those tools. Gateway on the other hand will be connecting 3rd party agents to Unity. We’re staggering access to both betas to make sure we don’t overwhelm the systems, which is why it’s an invite list. For the UAI Beta (Assistant & Generators), you can read more about what changes are included in the new beta over here on Discussions by our product manager Sam.

4 Likes
What is the official Unity strategy for agentic coding?
Why are game engines ignoring the potential of MCP?
20

Thanks for the clarification, for jumping in and clarifying this - really glad to hear AI Gateway is MCP-based and that you see MCP as the standard for agentic workflows. That’s exactly what many of us were hoping for.

A couple quick questions that would help everyone here understand what to expect:

Which clients will work first / best? Any info on Cursor, Antigravity, Windsurf, Claude Code, VS Code + Copilot, Visual Studio Insiders + Copilot? Even a “works / works with caveats / not yet” list would be super useful.

How will the connection look in practice? Is it basically “Unity Editor exposes MCP and the IDE connects” or is there an extra managed service involved?

What tools are you planning to expose via MCP? Scene + components, AssetDatabase, logs/tests are obvious - but FBX/ModelImporter tooling would be huge (e.g., feed the agent a list of clips + frame ranges and it sets up the import automatically).

Permissions/security: How granular is it? Per action/tool, per asset folder/type, team policies, etc.?

If MCP is the foundation and the official tools are solid, this can become the “just works” path for Unity + any AI IDE, without everyone maintaining their own fan-made bridge scripts.

Looking forward to trying it. We’ll sign up via the form — and we’re very interested in participating, especially if the focus is a robust, first-party MCP integration without “extra glue” required from third-party bridges.

3 Likes