Integrates with Hydra, the NixOS continuous integration server (and its forks such as Lix's Hydra), allowing agents to inspect projects, jobsets, evaluations, builds, build steps, logs and the build queue, and with an account to trigger evaluations, restart, cancel or bump builds, and create or edit projects and jobsets.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hydra-mcp show me the failed builds for nixpkgs:trunk"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Hydra, the Nix continuous integration server. It lets an agent look at projects, jobsets, evaluations, builds, build steps, logs and the queue, and (with an account) trigger evaluations, restart, cancel or bump builds and create or edit projects and jobsets. It works with NixOS Hydra and its forks (Lix's Hydra), and can talk to several instances at once.
Tool | What |
| Configured instances, the default, whether each can log in |
| Projects; a project's jobsets with error flags and build counts |
| Configuration, evaluation state, eval/fetch errors, recent evaluations |
| Evaluations (inputs/flake rev, counts), builds filtered by status |
| Status, timing, derivation, outputs, products, metrics; failed, running and newest build steps ( |
| Tail of a build's log or of one build step (e.g. the failed dependency) |
| A job's build in the newest evaluation and its latest successful build |
| Queue size, top of the queue, running builds |
| Projects, jobsets, jobs and builds by name or store path |
| Schedule a jobset evaluation ( |
| Build actions |
| Restart failed/aborted builds of an evaluation, cancel or bump them |
| Create, or change only the given fields of, a project or jobset |
There is also a debug_jobset prompt. Read tools work anonymously on public instances; write tools
log in with the configured account and need the matching Hydra role (create-projects,
restart-jobs, cancel-build, bump-to-front, or project ownership).
Notes on Hydra's API that the tools handle for you: boolean fields of projects and jobsets are true
whenever the key is present (so put_* omits false flags rather than sending 0), latest URLs
mean the latest successful build, build steps only exist on the HTML build page, and POST requests
need a Referer/Origin matching the instance.
Related MCP server: Jenkins MCP Server
~/.config/hydra-mcp/config.toml (or $HYDRA_MCP_CONFIG, or --config):
default = "nixos"
[instances.nixos]
url = "https://hydra.nixos.org"
[instances.mine]
url = "https://hydra.example.org"
username = "alice" # or username_file = "~/.secrets/hydra/username"
password_file = "~/.secrets/hydra/password"Passwords are only read from files, at login time; they never appear in the config, the process
arguments or tool results. URLs must be HTTPS (plain HTTP only for loopback), and the client never
follows redirects to another host. The file is re-read whenever it changes (including a Home
Manager switch that repoints its symlink), so no restart is needed. Without a config file, HYDRA_URL (default
https://hydra.nixos.org), HYDRA_USERNAME and HYDRA_PASSWORD_FILE describe a single instance.
nix run github:slopinger/hydra-mcp # stdio
uv run hydra-mcp --transport streamable-http # http://127.0.0.1:8002/mcp, no authenticationClaude Code: claude mcp add -s user hydra -- nix run github:slopinger/hydra-mcp, or point
command at a built result/bin/hydra-mcp. Logs, descriptions and error messages come from builds
and other users: clients should treat them as data, not instructions.
nix develop # editable environment with pytest
uv run pytest # offline tests: config, client against a mock Hydra, MCP stdio handshake
uv run pytest -m live # a few read-only calls to a real instance (HYDRA_LIVE_URL)
nix build && nix flake checkMIT licensed.
This server cannot be deployed
Inspect Depot builds, CI runs, job logs and Actions runners; retry or cancel CI runs.
Your agents' cloud for individuals and teams. Search, execute, packages, jobs, and credentials.
Trigger and inspect Codemagic CI builds, apps and artifacts.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
