We can't depend on Python and uv installation to use the package

[msanatan]

Feedback from submission:

Your package must not contain or depend on executables, installer programs, or other applications (.exe or other). (https://assetstore.unity.com/publishing/submission-guidelines, Section 1.5.a)

Guidelines:

Until further notice, the Asset Store is not accepting any submissions that include executables (for example, .exe, .apk, or other executables), embedded inside the package or as separate dependencies located in other websites.

So we can't depend on users having uv installed.

I think we could rewrite the server in C# using this: https://github.com/modelcontextprotocol/csharp-sdk. They still make a lot of breaking changes, but the core functionality works well. We'll still need dotnet to be installed to run a C# server, so the installer in Python should suffice

@justinpbarnett @dsarno @Scriptwonder

[msanatan]

Ok, looks like we'll have to explore C#, in a way that doesn't require dotnet. https://github.com/modelcontextprotocol/csharp-sdk supports Netstandard 2.0, so maybe we can host the server on the Unity thread, and connect via HTTP if Stdio is problematic.

I won't say slop, but there's a lot of code in this repo that's purely created by AI w/o any human oversight to encourage good design, reuse of code and other solid practices. So I think we should plan this out first, get a solid base set up by humans, and then AI generate on top of that.

[justinpbarnett]

Ok, looks like we'll have to explore C#, in a way that doesn't require dotnet. modelcontextprotocol/csharp-sdk supports Netstandard 2.0, so maybe we can host the server on the Unity thread, and connect via HTTP if Stdio is problematic.

I won't say slop, but there's a lot of code in this repo that's purely created by AI w/o any human oversight to encourage good design, reuse of code and other solid practices. So I think we should plan this out first, get a solid base set up by humans, and then AI generate on top of that.

Hmmm, this is an issue I ran into when I was initially building it. I first tried it like you're saying, keeping everything within Unity, but we need to keep an active connection to the MCP Client open. If I remember right that has to be done on the main thread, but that isn't possible because we also need to be able to perform actions on the main thread like instantiating objects and such.

[msanatan]

Ok, looks like we'll have to explore C#, in a way that doesn't require dotnet. modelcontextprotocol/csharp-sdk supports Netstandard 2.0, so maybe we can host the server on the Unity thread, and connect via HTTP if Stdio is problematic.
I won't say slop, but there's a lot of code in this repo that's purely created by AI w/o any human oversight to encourage good design, reuse of code and other solid practices. So I think we should plan this out first, get a solid base set up by humans, and then AI generate on top of that.

Hmmm, this is an issue I ran into when I was initially building it. I first tried it like you're saying, keeping everything within Unity, but we need to keep an active connection to the MCP Client open. If I remember right that has to be done on the main thread, but that isn't possible because we also need to be able to perform actions on the main thread like instantiating objects and such.

Yea, I think that's dawned on me too. We can't:

• Contain executables of any kind that run outside of Unity
• Require dependencies outside the Unity ecosystem
• Reliably run on the main thread

We can run on a background thread, but we have to manage the domain reloads and gracefully shut down/start up when those events happens - I think that's possible.

Maybe we support Streamable HTTP as the spec suggests: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http, so:

• Users who install from Git can connect via stdio as they do now
• Users who install via the asset store will connect to a hosted MCP server (Coplay will foot this bill), and be given the option to install locally for speed and privacy

It'll keep the plugin's footprint light on user's Unity Editor, super easy for users to set up (even those who install via Git), doesn't crash if the Unity editor crashes, etc

What do you think?

[msanatan]

Ok, v6.0.0 is out, which is pretty much this PR: #313. We don't show errors if Python/uv are uninstalled, and there's a way to download the MCP server. 🤞🏾

[msanatan]

Rejected again. This is the last feedback item to address: https://assetstore.unity.com/publishing/submission-guidelines

1.5.a Until further notice, the Asset Store is not accepting any submissions that include executables (for example, .exe, .apk, or other executables), embedded inside the package or as separate dependencies located in other websites.

FYI, this is how the plugin looks like on the Asset Store's version:

I've asked them to clarify if it's the download button or something else, e.g. the issue could be that users need to have an external IDE so our plugin isn't "self-contained" to Unity.

Once I get a response, we'll tackle this again.

If it's the download button, well, they can still configure MCP clients but nothing will really work, so that's pointless. The HTTP server that supports multiple connections may be our best bet, but that's not the quickest solution. If it's the required connections to external tools, nothing we do will get around that so we should stop this endeavour

[dsarno]

Frustrating, but thanks for all the work you've put into it. Hopefully they are reasonable about it.

The new UI looks great, by the way.

[msanatan]

After some internal discussions, we're trying again by configuring clients to use uvx and point to the server code on GitHub.

So nothing bundled, full functionality on the clients. I made some minor changes to get uvx to work, and now I'm adjusting the configs we generate

[msanatan]

If the next submission doesn't work, I'll implement the HTTP server I suggested earlier: #285 (comment)