Add NuGet MCP server

[sandrohanea]

Add Zed extension to launch NuGet MCP server via dnx.

Couldn't start the server reliably with dnx command directly, so I had to create some js adapter to run in with node.

It is based on: https://devblogs.microsoft.com/dotnet/nuget-mcp-server-preview/

Is there any plan to allow dnx command directly from:

        Ok(Command {
            command: "dnx".into(),
            args,
            env: vec![],
        })

or equivalent?

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @sandrohanea on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[sandrohanea]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[zed-industries-bot]

	Warnings
⚠️	This PR doesn't include changes to extensions.toml. If you are creating a new extension, add a new entry to it. If you are updating an existing extension, update the version number in the corresponding entry.

Generated by 🚫 dangerJS against 9010145

[MrSubidubi]

Thanks for this! Could you please briefly elaborate on the issues you ran into whilst attempting to directly invoke DLX? Can you try whether dotnet dnx uses more reliable results? I'd like to avoid the need for the wrapper script if possible.

Also, please follow the steps outlined as in https://zed.dev/docs/extensions/developing-extensions#publishing-your-extension as you are missing the entry in the extensions.toml here. Thanks!

[sandrohanea]

Hello @MrSubidubi,

Thanks for the follow-up! Here’s a concise summary of what I ran into:

• Returning dotnet (or dotnet dnx) as the command isn’t reliably resolved by the host on macOS when dotnet is installed via /etc/paths.d/dotnet. The spawned MCP process doesn’t seem to inherit that PATH entry, so the executable isn’t found and the server times out.
• Using an absolute dotnet path works reliably, but I don’t want to hardcode that since it would break on Windows.

From what I can see in Zed, the command returned by the extension is resolved relative to the extension directory, then executed via a non‑interactive shell with the environment inherited from Zed. There’s no extra PATH lookup in the extension API for context_server_command, and I don’t have access to a Worktree there to call which.

Relevant paths:

• crates/project/src/context_server_store/extension.rs
• crates/extension/src/extension.rs
• crates/context_server/src/transport/stdio_transport.rs
• crates/util/src/shell_builder.rs
• crates/extension_api/wit/since_v0.8.0/extension.wit
• crates/extension_api/src/extension_api.rs

Given that, I’d prefer not to hardcode paths or add platform‑specific PATH discovery in the extension. Would it be possible to expose a Worktree (or at least a which lookup) to context_server_command in the extension API? That would let extensions resolve binaries like dotnet in a cross‑platform way without wrapper scripts.

I see that currently, most of the extensions (if not all of them) are using zed::node_binary_path() to resolve the path for node but for other type of extensions, this is not currently possible.

Also noted on the publishing steps: I’ll add the missing entry in extensions.toml per the docs (once I'll update the extension to use the Worktree or any other which lookup):

• Publishing your extension

Thank you again!