Skip to main content
Glama
nixkeeper-mcp
by nixkeeper

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
NIXKEEPER_MCP_PAGENoThe web page the answers link to, when using another instance's data (default is https://nixkeeper.com/).
NIXKEEPER_MCP_CACHENoWhere files are kept (same as the --cache-dir option; default is $XDG_CACHE_HOME/nixkeeper-mcp, i.e. ~/.cache/nixkeeper-mcp).
NIXKEEPER_MCP_DASHBOARDNoPoints the server at another instance's dashboard data (a fork's).https://nixkeeper.com/data/
NIXKEEPER_MCP_DIGEST_OWNERNoThe 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

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 10 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityNo data
ResponsivenessSyncing