Support ephemeral execution for `dotnet tool run` similar to npx, docker, and uv

[JonDouglas]

Is your feature request related to a problem? Please describe.

In the AI-world, MCPs are becoming popular as a paradigm to share prompts, tools, and resources with a client. These are often run through package managers or docker environments in temporary fashion.

Describe the solution you'd like

Many ecosystems are using tools like npx, docker, uv, in various ways, but mostly in isolated, temporary environments where it downloads the dependency into an ephemeral environment, runs the thing, and then the environment is torn down

dotnet tool run could simply just support this by default if it isn't specified in the scope of a local environment where it would look for a local tool instead. Or a parameter to specify this is --ephermeral/temporary is fine too.

Additional context

https://github.com/modelcontextprotocol/servers

Related: #31103

[Redth]

It's also worth contemplating a similar short-hand for this like node has with npx being a package runner.

dotnet tool run --temp could be simplified to dnx or dntx.

[richlander]

I think there are definitely some missing scenarios here. It would be good to see some documented, from other ecosystems and/or fake .NET ones.

Docker doesn't strike me as another ecosystem in the way npx is. I think the way to use both Node and .NET in Docker is well understood at this point and folks are successful using it in both weird and wonderful ways.

"temporary" is a good goal. "secure" is not. We're not in the business of providing secure environments, but relying on other systems to do that. We should avoid creating an experience that is as convenient and attractive as curl | sh.

[JonDouglas]

I think there are definitely some missing scenarios here. It would be good to see some documented, from other ecosystems and/or fake .NET ones.

Docker doesn't strike me as another ecosystem in the way npx is. I think the way to use both Node and .NET in Docker is well understood at this point and folks are successful using it in both weird and wonderful ways.

"temporary" is a good goal. "secure" is not. We're not in the business of providing secure environments, but relying on other systems to do that. We should avoid creating an experience that is as convenient and attractive as curl | sh.

https://docs.npmjs.com/cli/v9/commands/npx?v=true

https://docs.astral.sh/uv/#tools

Let me clarify the scenario more explicitly.

We need a lightweight, temporary tool execution mechanism in the .NET ecosystem, similar to what Node's npx does. Specifically allowing quick, isolated, one-off execution of .NET-based tools without permanently affecting your global or local toolset.

The comparison to Docker wasn't about mimicking DOcker or containerization itself, rather illustrating that some developers use container tools to temporarily execute commands without polluting their permanent environment. Docker itself is not the intended analogy here but highlights the concept of transient tool exceution.

We’re also not inherently guaranteeing a secure sandbox or replicating something like curl | sh. Security concerns would continue to be addressed through existing, trusted mechanisms. This solution would rely heavily on our established NuGet infrastructure.

This approach provides clear usability benefits and has already been implemented in multiple ecosystems. Allowing .NET devs to execute tools quickly, frictionlessly, and temporarily would significantly improve many scenarios, especially for MCP.

[gaoconggit]

https://github.com/Redth/npx-dntx

I also think dotnet's mcp needs this

[stvansolano]

Would be possible to extend @Redth npx-dntx to run/support packages hosted in nuget directly? That will aim MCP developed via the SDK and boost NuGet usage itself

e.g: npx dntx @nuget/modelcontextprotocol/csharp-sdk/samples/QuickstartWeatherServer (technically, whatever MCP ready to use which just requires passing an argument, like OPEN_API_KEY)

cc @stephentoub

[baronfel]

See also #31103 for related discussion/spec/planning.