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?