🚨 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経由でのサーバー実行をサポートしています（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をネイティブでサポートしていません。2つのサポートされたパスがあります：
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千以上のオプション
nix-darwin - Appleがドキュメント化していない1千以上のmacOS設定
Nixvim - NuschtOS search を介したNeovim設定のための5千以上のオプション
FlakeHub - FlakeHub.com レジストリからの600以上のFlake
Noogle - noogle.dev を介した型シグネチャ付きの2千以上のNix関数
NixOS Wiki - wiki.nixos.org からのコミュニティドキュメントとガイド
nix.dev - nix.dev からの公式Nixチュートリアルとガイド
パッケージバージョン - NixHub.io を介したコミットハッシュ付きの過去バージョン
バイナリキャッシュステータス - cache.nixos.org でパッケージがキャッシュされているか、ダウンロードサイズとともに確認
ローカルFlake入力 - Nixストアから直接、ピン留めされたFlake依存関係を探索（Nixが必要）
たった2つです。AIのコンテキストウィンドウは無限ではないため、17個のツールを2つに統合しました。
合計約1,030トークン。 以上です。他のMCPサーバーがブラックフライデーのようにコンテキストを占有している間、私たちは隅でミニマリストなティーを飲んでいます。あなたのAIは、肥大化することなくNixOSのスーパーパワーを手に入れます。
nix - 統合クエリツールすべてを支配する1つのツール：
nix(action, query, source, type, channel, limit)アクション | 内容 |
| パッケージ、オプション、プログラム、またはFlakeを検索 |
| パッケージやオプションの詳細情報を取得 |
| カウントとカテゴリを取得 |
| プレフィックスごとにHome Manager/Darwinオプションを閲覧 |
| 利用可能なNixOSチャンネルを一覧表示 |
| NixストアからローカルのFlake入力を探索 |
| パッケージのバイナリキャッシュステータスを確認 |
ソース | クエリ対象 |
| パッケージ、オプション、プログラム |
| Home Managerオプション |
| nix-darwinオプション |
| コミュニティFlake (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-nixosNixユーザーの場合：
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 ];または、提供されているオーバーレイを使用して直接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.
