🚨 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"]
}
}
}Теперь у вашего ИИ есть доступ к реальным данным NixOS вместо выдумок. Пожалуйста.
FastMCP поддерживает запуск этого сервера через HTTP по 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-nixosStateless 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 — более 130 тысяч реально существующих пакетов
Опциях NixOS — более 23 тысяч способов настройки вашей системы
Home Manager — более 5 тысяч опций для любителей dotfiles
nix-darwin — более 1 тысячи настроек macOS, которые не документирует Apple
Nixvim — более 5 тысяч опций для конфигурации Neovim через поиск NuschtOS
FlakeHub — более 600 флейков из реестра FlakeHub.com
Noogle — более 2 тысяч функций Nix с сигнатурами типов через noogle.dev
NixOS Wiki — документация сообщества и руководства с wiki.nixos.org
nix.dev — официальные руководства и туториалы по Nix с nix.dev
Версиях пакетов — исторические версии с хешами коммитов через NixHub.io
Статусе бинарного кеша — проверка наличия пакетов в кеше cache.nixos.org с размерами загрузки
Локальных входных данных флейков — изучение ваших закрепленных зависимостей флейков прямо из хранилища Nix (требуется Nix)
Всего два. Мы объединили 17 инструментов в 2, потому что контекстное окно вашего ИИ не бесконечно.
Всего ~1030 токенов. Вот и всё. Пока другие MCP-серверы поглощают ваш контекст, как будто это «Черная пятница», мы попиваем минималистичный чай в сторонке. Ваш ИИ получает суперсилы NixOS без лишнего «мусора».
nix — Универсальный инструмент запросовОдин инструмент, чтобы править всеми:
nix(action, query, source, type, channel, limit)Действие | Что делает |
| Поиск пакетов, опций, программ или флейков |
| Получение подробной информации о пакете или опции |
| Получение количества и категорий |
| Просмотр опций Home Manager/Darwin по префиксу |
| Список доступных каналов NixOS |
| Изучение локальных входных данных флейков из хранилища Nix |
| Проверка статуса бинарного кеша для пакетов |
Источник | Что запрашивает |
| Пакеты, опции, программы |
| Опции Home Manager |
| Опции nix-darwin |
| Флейки сообщества (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 ];Или используйте флейк напрямую с предоставленным оверлеем:
# 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
Jetify — создатели Devbox и NixHub
Noogle — поисковая система функций Nix
NuschtOS — инфраструктура статического поиска опций, обеспечивающая поддержку Nixvim
Nixvim — фреймворк конфигурации Neovim для Nix
MIT — потому что делиться — значит заботиться.
Создано Джеймсом Бринком. Поддерживается мазохистами-энтузиастами, которые любят 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.
