nixkeeper-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NIXKEEPER_MCP_PAGE | No | The web page the answers link to, when using another instance's data (default is https://nixkeeper.com/). | |
| NIXKEEPER_MCP_CACHE | No | Where files are kept (same as the --cache-dir option; default is $XDG_CACHE_HOME/nixkeeper-mcp, i.e. ~/.cache/nixkeeper-mcp). | |
| NIXKEEPER_MCP_DASHBOARD | No | Points the server at another instance's dashboard data (a fork's). | https://nixkeeper.com/data/ |
| NIXKEEPER_MCP_DIGEST_OWNER | No | The owner of the digest repositories to read (points at a fork's digests). | nixkeeper |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| packageB | Everything nixkeeper knows about one nixpkgs package: its nixpkgs version against upstream's (Repology, nixkeeper's own update checks), master's version, Hydra's latest builds on each platform with why a failure failed and when it last built, the update bot's (nixpkgs-update, r-ryantm) latest attempt and when it tries next, open update PRs and other PRs and issues, CVEs and advisories with nixkeeper's verdict against nixpkgs' version, maintainers and teams; an update merged into staging or staging-next on its way to master (stagingPR, and how it builds there), and whether staging-next breaks the package (stagingNextBreaks: a forecast). newerInDigests: what the hourly digests have that's newer than the dashboard's last sync. |
| find_packagesA | Find nixpkgs packages by name (exact, then starting with, then containing the query), each with its status: failed, outdated, up to date, vulnerable. |
| needs_attentionA | Packages that need attention, as nixkeeper's dashboard counts them: a build failing on Hydra, outdated, vulnerable, or a CVE fix to backport; optionally only one maintainer's (GitHub handle), one team's or one list's, one kind, one platform. Without maintainer, team or list: all of nixpkgs (thousands: narrow with kind). With a maintainer or team, also the open PRs they can merge now with the merge bot (canMerge). |
| overviewA | All of nixpkgs at a glance, from nixkeeper's dashboard: how many packages are outdated, failing to build, failing their update attempts, vulnerable, broken; the newest and longest-standing of each; the failing dependencies blocking the most builds; why builds and the update bot fail, grouped; what was fixed in the last week. |
| build_failuresA | Search Hydra's builds of nixpkgs master (the builds digest, hourly) that aren't ok: failed (the package's own failure, with why from its log and an excerpt), dependency (blockedBy: which dependency failed), unfinished, queued. Newest first, or longest failing first. With the last success of each. |
| pull_requestsA | Search nixpkgs' open pull requests (the PR digest, hourly), with what the digest makes of each: its buckets (update, init, drop, tiny, bot, python, ...), the update it makes and how it compares with nixpkgs now (state), whether a maintainer can merge it with the merge bot, whether it blocks the update bot, duplicates, and packages it touches that fail on Hydra (maybe its fix). |
| issuesA | Search nixpkgs' open issues by title (the PR digest, hourly). Build-failure issues have hydra: what Hydra builds now say (builds: a candidate to close; failing; waiting; removed; ...); update requests have update: whether nixpkgs has the version asked (done, partly, open) and the update bot's plans. |
| update_attemptsB | nixpkgs-update's (r-ryantm) latest attempt at packages (the update-bot digest, every 3 hours): its outcome, versions, PR, why it failed with a log excerpt; for one package, also its place in the bot's queue and when it's expected to try again. |
| vulnerabilitiesA | CVEs from the NixOS security tracker (with its issue, severity, affected versions, status on master and the release branches) and OSV advisories for language packages (the vulnerabilities digest, hourly): one package's, one CVE's (or NIXPKGS-..., or an advisory id), or else the CVEs affecting some package now, worst first. |
| data_statusB | When each digest and the dashboard were last made and read (their meta.json files), and what this server has cached. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools target clearly different resources or actions: find_packages searches, package retrieves one package, issues and pull_requests cover distinct artifact types, and vulnerabilities and update_attempts are specialized. There is some conceptual overlap among overview, needs_attention, and build_failures because all surface problematic packages/builds, but the detailed descriptions mostly make the boundaries usable.
All names use snake_case, but the convention is mixed: find_packages is verb_noun while package, overview, issues, vulnerabilities, pull_requests, build_failures, needs_attention, data_status, and update_attempts are noun/resource phrases. Singular/plural usage also varies (package vs issues/pull_requests), so the pattern is readable but not strongly predictable.
Ten tools is well within a reasonable range and fits the server's monitoring scope. Each tool covers a distinct area of nixpkgs health: package lookup/detail, build failures, dashboard summaries, issues, PRs, vulnerabilities, update-bot attempts, and data freshness.
The surface covers the main read-only monitoring lifecycle: package discovery and detail, aggregate health, attention lists, build failures, issues, PRs, CVEs/advisories, update attempts, and digest freshness. Minor gaps exist around deeper direct issue/PR detail or explicit maintainer/team listing, but core workflows appear covered.