🚨 无需 Nix/NixOS！ 适用于任何系统 - Windows、macOS、Linux。你只是在查询 API。
{
"mcpServers": {
"nixos": {
"command": "uvx",
"args": ["mcp-nixos"]
}
}
}
{
"mcpServers": {
"nixos": {
"command": "nix",
"args": ["run", "github:utensils/mcp-nixos", "--"]
}
}
}
{
"mcpServers": {
"nixos": {
"command": "docker",
"args": ["run", "--rm", "-i", "ghcr.io/utensils/mcp-nixos"]
}
}
}你的 AI 现在可以访问真实的 NixOS 数据，而不是胡编乱造。不客气。
FastMCP 支持通过 URL 在 HTTP 上运行此服务器（MCP 端点默认为 /mcp）。
# Run an HTTP MCP server at http://127.0.0.1:8000/mcp
MCP_NIXOS_TRANSPORT=http MCP_NIXOS_HOST=127.0.0.1 MCP_NIXOS_PORT=8000 mcp-nixosSTDIO（默认）：
MCP_NIXOS_TRANSPORT=stdio mcp-nixos自定义路径：
MCP_NIXOS_TRANSPORT=http MCP_NIXOS_PATH=/api/mcp mcp-nixos无状态 HTTP（禁用每个客户端的会话状态）：
MCP_NIXOS_TRANSPORT=http MCP_NIXOS_STATELESS_HTTP=1 mcp-nixosPi 不原生支持 MCP。有两种支持的路径：
A. pi-mcp-adapter（推荐 — 支持 MCP，单一事实来源）：
pi install npm:pi-mcp-adapter然后添加到 ~/.pi/agent/mcp.json：
{
"mcpServers": {
"nixos": {
"command": "uvx",
"args": ["mcp-nixos"],
"lifecycle": "lazy"
}
}
}B. 项目本地扩展（克隆 + 运行）： 此仓库附带 .pi/extensions/mcp-nixos.ts，当你在此克隆的仓库中运行 pi 时会自动加载。可选：运行 cd .pi && npm install 以进行编辑器类型解析。无论哪种方式，Pi 都会运行它。
Related MCP server: Grounded Code MCP
一个提供准确、实时信息的 MCP 服务器，涵盖：
NixOS 软件包 - 13 万+ 真实存在的软件包
NixOS 选项 - 2.3 万+ 配置系统的方法
Home Manager - 5 千+ 供点文件（dotfile）爱好者使用的选项
nix-darwin - 1 千+ 苹果未记录的 macOS 设置
Nixvim - 5 千+ 通过 NuschtOS search 进行 Neovim 配置的选项
FlakeHub - 600+ 来自 FlakeHub.com 注册表的 flakes
Noogle - 2 千+ 带有类型签名的 Nix 函数，来自 noogle.dev
NixOS Wiki - 来自 wiki.nixos.org 的社区文档和指南
nix.dev - 来自 nix.dev 的官方 Nix 教程和指南
软件包版本 - 通过 NixHub.io 获取带有提交哈希的历史版本
二进制缓存状态 - 检查软件包是否在 cache.nixos.org 上缓存及其下载大小
本地 flake 输入 - 直接从 Nix store 探索你固定的 flake 依赖项（需要 Nix）
只有两个。我们将 17 个工具合并为 2 个，因为你的 AI 上下文窗口不是无限的。
总计约 1,030 个 token。 就这样。当其他 MCP 服务器像黑色星期五一样占用你的上下文时，我们正在角落里品尝极简主义的茶。你的 AI 获得了 NixOS 的超能力，而没有臃肿的负担。
nix - 统一查询工具一个统治一切的工具：
nix(action, query, source, type, channel, limit)操作 | 功能 |
| 搜索软件包、选项、程序或 flakes |
| 获取有关软件包或选项的详细信息 |
| 获取计数和类别 |
| 按前缀浏览 Home Manager/Darwin 选项 |
| 列出可用的 NixOS 频道 |
| 从 Nix store 探索本地 flake 输入 |
| 检查软件包的二进制缓存状态 |
来源 | 查询内容 |
| 软件包、选项、程序 |
| Home Manager 选项 |
| nix-darwin 选项 |
| 社区 flakes (search.nixos.org) |
| FlakeHub 注册表 (flakehub.com) |
| Nixvim Neovim 配置选项 |
| Nix 函数签名和文档 (noogle.dev) |
| NixOS Wiki 文章 (wiki.nixos.org) |
| 官方 Nix 文档 (nix.dev) |
| 软件包元数据和存储路径 (nixhub.io) |
示例：
# Search NixOS packages
nix(action="search", query="firefox", source="nixos", type="packages")
# Get package info
nix(action="info", query="firefox", source="nixos", type="package")
# Search Home Manager options
nix(action="search", query="git", source="home-manager")
# Browse darwin options
nix(action="options", source="darwin", query="system.defaults")
# Search Nixvim options
nix(action="search", query="telescope", source="nixvim")
# Get Nixvim option info
nix(action="info", query="plugins.telescope.enable", source="nixvim")
# Search FlakeHub
nix(action="search", query="nixpkgs", source="flakehub")
# Get FlakeHub flake info
nix(action="info", query="NixOS/nixpkgs", source="flakehub")
# Search Noogle for Nix functions
nix(action="search", query="mapAttrs", source="noogle")
# Get Noogle function info
nix(action="info", query="lib.attrsets.mapAttrs", source="noogle")
# Browse Noogle function categories
nix(action="options", source="noogle", query="lib.strings")
# Search NixOS Wiki
nix(action="search", query="nvidia", source="wiki")
# Get Wiki page info
nix(action="info", query="Flakes", source="wiki")
# Search nix.dev documentation
nix(action="search", query="packaging tutorial", source="nix-dev")
# Search NixHub for package metadata
nix(action="search", query="nodejs", source="nixhub")
# Get detailed package info from NixHub (license, homepage, store paths)
nix(action="info", query="python", source="nixhub")
# Check binary cache status
nix(action="cache", query="hello")
# Check cache for specific version
nix(action="cache", query="python", version="3.12.0")
# Check cache for specific system
nix(action="cache", query="firefox", system="x86_64-linux")
# Get stats
nix(action="stats", source="nixos", channel="stable")
# List local flake inputs (requires Nix)
nix(action="flake-inputs", type="list")
# Browse files in a flake input
nix(action="flake-inputs", type="ls", query="nixpkgs:pkgs/by-name")
# Read a file from a flake input
nix(action="flake-inputs", type="read", query="nixpkgs:flake.nix")nix_versions - 软件包版本历史查找带有 nixpkgs 提交哈希的历史版本。输出包括：
软件包元数据（许可证、主页、程序，如果可用）
每个版本的平台可用性（Linux/macOS）
用于可重复构建的 Nixpkgs 提交哈希
Nix 表达式的属性路径
nix_versions(package, version, limit)示例：
# List recent versions with metadata
nix_versions(package="python", limit=5)
# Find specific version
nix_versions(package="nodejs", version="20.0.0")你不需要安装 Nix。 这可以在任何运行 Python 的地方运行。
# Run directly (no install)
uvx mcp-nixos
# Or install
pip install mcp-nixos对于 Nix 用户：
nix run github:utensils/mcp-nixos
nix profile install github:utensils/mcp-nixosmcp-nixos 可在 nixpkgs 中找到：
# NixOS (configuration.nix)
environment.systemPackages = [ pkgs.mcp-nixos ];
# Home Manager (home.nix)
home.packages = [ pkgs.mcp-nixos ];
# nix-darwin (darwin-configuration.nix)
environment.systemPackages = [ pkgs.mcp-nixos ];或者使用提供的 overlay 直接使用 flake：
# flake.nix
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
mcp-nixos.url = "github:utensils/mcp-nixos";
};
outputs = { self, nixpkgs, mcp-nixos, ... }: {
# Example: NixOS configuration
nixosConfigurations.myhost = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [{
nixpkgs.overlays = [ mcp-nixos.overlays.default ];
environment.systemPackages = [ pkgs.mcp-nixos ];
}];
};
# Example: Home Manager standalone
homeConfigurations.myuser = home-manager.lib.homeManagerConfiguration {
pkgs = import nixpkgs {
system = "x86_64-linux";
overlays = [ mcp-nixos.overlays.default ];
};
modules = [{
home.packages = [ pkgs.mcp-nixos ];
}];
};
};
}nix develop # Enter dev shell
nix build # Build package
pytest tests/ # Run tests
ruff check . # Lint
ruff format . # Format
mypy mcp_nixos/ # Type checkNixHub.io - 软件包版本历史
search.nixos.org - 官方 NixOS 搜索
FlakeHub - Determinate Systems 的 Flake 注册表
Jetify - Devbox 和 NixHub 的创建者
Noogle - Nix 函数搜索引擎
NuschtOS - 支持 Nixvim 的静态选项搜索基础设施
Nixvim - Nix 的 Neovim 配置框架
MIT - 因为分享就是关怀。
由 James Brink 创建。由喜欢 Nix 的受虐狂爱好者维护。
Query NixOS, Home Manager, Darwin, FlakeHub, flakes, Nixvim, NVF, Wiki, nix.dev, Noogle, NixHub.
Use this tool for anything touching nixpkgs, Nix channels, flakes, NixOS / home-manager /
darwin options, the binary cache, or /nix/store paths — even when you think you know the
answer. Your training data lags nixpkgs by months. Prefer this over nix search, scraping
search.nixos.org, or running gh api against NixOS/nixpkgs.
INTENTS → CALLS (copy the JSON shape exactly): "is package X in channel Y?" → {"action": "info", "query": "X", "channel": "Y"} "search for package X" → {"action": "search", "query": "X"} "which channels are available?" → {"action": "channels"} "which commit did channel X index?" → {"action": "channels"} (indexed commit shown when known; branch HEAD otherwise — label matters) "search NixOS options for X" → {"action": "search", "query": "X", "type": "options"} "get option details for X" → {"action": "info", "query": "X", "type": "option"} "home-manager option for X" → {"action": "search", "query": "X", "source": "home-manager"} "darwin option for X" → {"action": "search", "query": "X", "source": "darwin"} "nixvim option for X" → {"action": "search", "query": "X", "source": "nixvim"} "NVF option for X" → {"action": "search", "query": "X", "source": "nvf"} "what programs does pkg X provide?" → {"action": "search", "query": "X", "type": "programs"} "count packages/options" → {"action": "stats"} "browse hm option tree under P" → {"action": "browse", "query": "P", "source": "home-manager"} "does X have a binary cache?" → {"action": "cache", "query": "X"} "search the NixOS wiki for X" → {"action": "search", "query": "X", "source": "wiki"} "search nix.dev docs" → {"action": "search", "query": "X", "source": "nix-dev"} "read a nix.dev page" → {"action": "info", "query": "tutorials/nix-language", "source": "nix-dev"} "list inputs of current flake" → {"action": "flake-inputs"} "ls inside flake input X" → {"action": "flake-inputs", "type": "ls", "query": "X"} "read /nix/store/... file" → {"action": "store", "type": "read", "query": "/nix/store/..."} "ls /nix/store/... dir" → {"action": "store", "type": "ls", "query": "/nix/store/..."}
For package version history ("which commit shipped firefox 150?", "when was node 18 added?"),
use the separate nix_versions tool — it returns commit hashes, attribute paths, and dates.
Notes:
To search NixOS options, use action=search with type=options. Do NOT use action=browse for source=nixos — browse is for walking a pre-indexed option tree and only works with home-manager, darwin, nixvim, nvf, or noogle.
For source=nvf, canonical option paths are vim.. The shorthand programs.nvf.vim. and NixOS/Home Manager module path programs.nvf.settings.vim.* are normalized automatically.
For source=nix-dev, action=info returns the page markdown. The query may be a bare docname like "tutorials/nix-language", the URL printed by nix-dev search ("https://nix.dev/tutorials/nix-language"), or a rendered ".html" URL.
action=info for packages matches on the exact attribute path first, then the exact pname. If multiple packages share a pname (e.g. firefox / firefox-esr / firefox-mobile), the canonical attribute wins and the response flags the disambiguation explicitly.
Omit parameters you don't need; do not pass empty strings for optional args.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Sub-type of query. For source=nixos with action=search, one of: packages, options, programs, flakes. For source=nixos with action=info, one of: package, option. For flake-inputs, one of: list, ls, read. For store, one of: ls, read. Ignored by most other sources. | packages |
| limit | No | Max results. 1-100 (or 1-2000 for flake-inputs/store read). | |
| query | No | Search term for 'search', exact name for 'info', prefix path for 'browse'. For flake-inputs: input_name or input:path. For store: absolute /nix/store/ path. Leave empty for 'stats'/'channels'. | |
| action | Yes | One of: search, info, stats, browse, channels, flake-inputs, cache, store. Use 'search' for keyword lookup, 'info' for details about a specific name, 'browse' to walk an option hierarchy by prefix (home-manager/darwin/nixvim/nvf/noogle only; 'options' is accepted as a legacy alias). 'store' reads files or lists directories at an explicit /nix/store/ path. | |
| source | No | Data source for search/info/stats/browse/cache. One of: nixos (default), home-manager, darwin, flakes, flakehub, nixvim, nvf, wiki, nix-dev, noogle, nixhub. For action=flake-inputs, this may instead be a path to a flake directory; omit/default to use the current project. Ignored by action=store. | nixos |
| system | No | Only used by action=cache. System arch e.g. x86_64-linux. Empty for all. | |
| channel | No | NixOS channel: unstable (default), stable, or a release like 25.05. | unstable |
| version | No | Only used by action=cache. Package version (default: latest). | latest |
| 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 transparency burden. It is transparent about limitations (training data lag), matching rules, normalization behavior, and the browse action's source restrictions. It does not explicitly state read-only/side-effect behavior, but all listed actions are query-like.
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 long but densely informative: intent mappings cover many cases, notes consolidate edge cases, and no sections are redundant or fluff. Each line earns its place.
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?
It is complete for a complex tool: it covers search/info/browse/stats/channels/flake-inputs/cache/store, documents source-specific behavior, points to the sibling nix_versions tool for version history, and notes canonicalization and disambiguation behavior.
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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds significant extra semantic value through intent mappings and clarifying notes for type/source combinations, defaults, and parameter omission guidance.
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 identifies the tool as the Nix ecosystem querying tool for packages, options, channels, flakes, caches, and docs. It is distinguished from the sibling nix_versions tool explicitly.
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?
It provides extensive guidance: when to prefer this tool over alternatives, explicit intent-to-call mappings, and notes about which source/action combinations are valid and which to avoid. It also directs version-history queries to nix_versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get package version history from NixHub.io.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1-50 | |
| package | Yes | Package name | |
| version | No | Specific version to find |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. The verb 'Get' implies a read-only operation, which suggests no destructive side effects. However, the description does not explicitly state side effects, authorization requirements, or other behavioral implications, so it provides only implicit transparency.
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, concise sentence with no superfluous words. It effectively conveys the purpose without unnecessary elaboration, making it easy to parse and understand.
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?
The tool is simple and the description is adequate given the presence of an output schema. It does not address potential error handling or edge cases, but these are likely covered by the output schema. Overall, the description provides sufficient context for a straightforward 'get history' operation.
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 100% (all three parameters have descriptions). The parameter descriptions are brief but clear ('Package name', 'Specific version to find', '1-50' for limit). The tool description does not add additional semantic detail beyond the schema, so the baseline score of 3 is appropriate.
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 'Get package version history from NixHub.io' uses a specific verb ('Get') and clearly identifies the resource (package version history) and source (NixHub.io). It effectively distinguishes this tool from the sibling 'nix' by being more specific about the operation performed.
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 does not provide any guidance on when to use this tool versus the sibling tool 'nix'. There is no mention of alternative conditions or scenarios, leaving the agent without clear decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.1.0nix1 field changedInput schema / properties / action / descriptionPrevious value: -"One of: search, info, stats, browse, channels, flake-inputs, cache, store. Use 'search' for keyword lookup, 'info' for details about a specific name, 'browse' to walk an option hierarchy by prefix (home-manager/darwin/nixvim/nvf/noogle only). 'store' reads files or lists directories at an explicit /nix/store/ path."New value: +"One of: search, info, stats, browse, channels, flake-inputs, cache, store. Use 'search' for keyword lookup, 'info' for details about a specific name, 'browse' to walk an option hierarchy by prefix (home-manager/darwin/nixvim/nvf/noogle only; 'options' is accepted as a legacy alias). 'store' reads files or lists directories at an explicit /nix/store/ path."v3.0.0nix2 fields changedInput schema / properties / action / descriptionPrevious value: -"One of: search, info, stats, browse, channels, flake-inputs, cache, store. Use 'search' for keyword lookup, 'info' for details about a specific name, 'browse' to walk an option hierarchy by prefix (home-manager/darwin/nixvim/noogle only). 'store' reads files or lists directories at an explicit /nix/store/ path."New value: +"One of: search, info, stats, browse, channels, flake-inputs, cache, store. Use 'search' for keyword lookup, 'info' for details about a specific name, 'browse' to walk an option hierarchy by prefix (home-manager/darwin/nixvim/nvf/noogle only). 'store' reads files or lists directories at an explicit /nix/store/ path."Input schema / properties / source / descriptionPrevious value: -"Data source for search/info/stats/browse/cache. One of: nixos (default), home-manager, darwin, flakes, flakehub, nixvim, wiki, nix-dev, noogle, nixhub. For action=flake-inputs, this may instead be a path to a flake directory; omit/default to use the current project. Ignored by action=store."New value: +"Data source for search/info/stats/browse/cache. One of: nixos (default), home-manager, darwin, flakes, flakehub, nixvim, nvf, wiki, nix-dev, noogle, nixhub. For action=flake-inputs, this may instead be a path to a flake directory; omit/default to use the current project. Ignored by action=store."v2.1.0darwin_infodarwin_list_optionsdarwin_options_by_prefixdarwin_searchdarwin_statshome_manager_infohome_manager_list_optionshome_manager_options_by_prefixhome_manager_searchhome_manager_statsnixnix_versionsnixhub_find_versionnixhub_package_versionsnixos_channelsnixos_flakes_searchnixos_flakes_statsnixos_infonixos_searchnixos_statsScored across 2 tools
The two tools serve distinct purposes: 'nix' is a general-purpose Nix query tool, while 'nix_versions' is specifically for package version history. However, 'nix' is a broad catch-all that could potentially overlap with version queries, requiring careful description reading.
Both tool names start with 'nix', but one is a bare noun and the other uses an underscore suffix. The names are readable and related, though not following a strict verb_noun or consistent structural pattern.
Only two tools are exposed, which feels thin for the broad Nix-related scope. However, the primary 'nix' tool encapsulates many actions, making the count borderline rather than severely inadequate.
The tools cover a wide range of Nix operations: packages, options, channels, flakes, store paths, docs, cache, and version history. No major gaps are apparent for the stated domain.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
