🚨 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천 개 이상의 옵션
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 필요)
단 두 개뿐입니다. AI의 컨텍스트 창은 무한하지 않기 때문에 17개의 도구를 2개로 통합했습니다.
총 약 1,030 토큰. 그게 전부입니다. 다른 MCP 서버들이 블랙 프라이데이처럼 컨텍스트를 독점할 때, 우리는 구석에서 미니멀리스트 차를 마시고 있습니다. AI는 군더더기 없이 NixOS 슈퍼파워를 얻게 됩니다.
nix - 통합 쿼리 도구모든 것을 제어하는 하나의 도구:
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.
