Provides ephemeral Nix-backed execution environments for running Lua code with on-demand package dependencies from nixpkgs.
Provides ephemeral Nix-backed execution environments for running Node.js code with on-demand package dependencies from nixpkgs.
Provides ephemeral Nix-backed execution environments for running Python code with on-demand package dependencies from nixpkgs.
Provides ephemeral Nix-backed execution environments for running Ruby code with on-demand package dependencies from nixpkgs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-omnienv-nix run a Python script that uses pandas to calculate average sales"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that spins up Nix-backed, polyglot ephemeral environments. It uses nix shell to build disposable toolchains for interpreted stacks (Python, Node.js, Ruby, R, Lua; extendable) and runs your command inside that shell. Package availability depends on nixpkgs (e.g., python313Packages.requests, rPackages.misty, nodePackages.sloc).
Coding agents often need ad-hoc Python/Node/Ruby/R/Lua deps. Preloading everything is noisy; venvs clutter a system.
With Nix on the host, this server asks for packages on demand, pulls them into the store, and leaves the rest of the environment clean—no venvs or global installs.
Runs over MCP (stdio transport) so agent clients can call the tools directly.
Related MCP server: Node.js Sandbox MCP Server
list_languages — enumerate supported languages and their base Nix packages.
run_in_env(language, command, extra_packages?, timeout_seconds?) — launch a nix shell with base + extras and execute command. Returns JSON: stdout, stderr, exit_code.
# Try it ad-hoc
nix shell github:StealthBadger747/mcp-omnienv-nix -c mcp-omnienv-nixHook into your MCP client (stdio transport). Example config shape:
{
"mcpServers": {
"mcp-omnienv-nix": {
"command": "mcp-omnienv-nix"
}
}
}Edit SUPPORTED_LANGUAGES in mcp_omnienv_nix/server.py to add a language and its base packages.
run_in_env validates extra packages against a simple regex and appends them to the nix shell invocation.
# Nix dev shell with deps + pytest
nix develop . -c pytest
# Run integration tests (hit nix shell for real package resolution)
MCP_OMNIENV_INTEGRATION=1 nix develop . -c pytest -m integrationMIT.
List supported languages and their base Nix packages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it returns all languages at once, if there's pagination, error conditions, or performance characteristics. This leaves significant behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any extraneous information. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, has output schema), the description is adequate but minimal. It covers the basic purpose but lacks usage guidelines and behavioral details, which are important even for simple tools. The presence of an output schema reduces the need to describe return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, this is acceptable, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('supported languages and their base Nix packages'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'run_in_env_impl', which appears to serve a different function (execution vs. listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or in what context it should be invoked. With a sibling tool present, this lack of comparative usage information is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a shell command in a disposable Nix shell for the chosen language.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | ||
| command | Yes | ||
| extra_packages | No | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the shell is 'disposable' (implying ephemeral/temporary) and specifies the environment ('Nix shell for the chosen language'), which adds some context. However, it lacks critical details like security implications, resource limits, error handling, or what 'run' entails (e.g., synchronous execution, output capture). For a tool that executes arbitrary commands, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Run a shell command') and context. There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing commands in a specialized environment), lack of annotations, and 0% schema description coverage, the description is incomplete. It does cover the basic purpose and environment, but since an output schema exists, it doesn't need to explain return values. However, it misses critical behavioral and parameter details needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only implicitly references 'language' and 'command' ('shell command in a disposable Nix shell for the chosen language'), but doesn't explain what 'language' entails (e.g., programming language, version), what 'command' format is expected, or mention 'extra_packages' and 'timeout_seconds' at all. With 4 parameters and no schema descriptions, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a shell command') and the resource/environment ('in a disposable Nix shell for the chosen language'), making the purpose immediately understandable. It doesn't explicitly differentiate from the sibling tool 'list_languages', which serves a completely different function, but the distinction is obvious enough that a 4 is appropriate rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or constraints. It mentions the environment ('disposable Nix shell for the chosen language') but doesn't explain why one would choose this over other execution methods or what scenarios it's designed for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: list_languages enumerates available options, while run_in_env_impl executes commands in a specific environment. There is no overlap or ambiguity between them.
The naming is mixed: list_languages follows a verb_noun pattern, but run_in_env_impl uses a less conventional verb_in_noun_impl style. While readable, the inconsistency in naming conventions is noticeable.
With only 2 tools, the server feels thin for its apparent scope of managing language environments in Nix. A typical server in this domain would include more operations like creating, updating, or inspecting environments, making this count borderline inadequate.
The toolset is severely incomplete for managing Nix language environments. It lacks essential operations such as creating, updating, or deleting environments, and provides no way to inspect or modify specific environment configurations, leaving significant gaps in coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Run Python code in a secure sandbox without local setup. Declare inline dependencies and execute s…
Execute code in 8 languages (Python, JS, TS, Go, Java, C++, C, Bash) in gVisor sandboxes.
Coding agents build full-stack apps in persistent workspaces and share them by link.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/StealthBadger747/mcp-omnienv-nix'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
