Provides tools for interacting with Hydra, the NixOS continuous integration server, including projects, jobsets, evaluations, builds, build steps and logs, the build queue, search, and authenticated actions such as triggering evaluations, restarting or cancelling builds, and managing 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 why did my latest Hydra build fail?"
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: MCP Jenkins
~/.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:slopmaxxer/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:slopmaxxer/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.
Move a queued build to the front of the queue (needs bump rights).
Inputs: build_id (required), instance. Returns: object
Cancel a queued or running build (needs cancel rights). Confirm with the user first.
Inputs: build_id (required), instance. Returns: object
Get a build: status, timing, derivation, outputs, products, metrics and its build steps.
steps="relevant" (default) lists failed and running steps plus the newest few; "all" lists every step (large for big closures). Failed steps name the dependency behind "dependency failed".
Inputs: build_id (required), steps, instance, recent_steps. Returns: object
Get the last lines of a build's log, or of one of its build steps (e.g. the failed dependency).
Inputs: build_id (required), step, instance, tail_lines. Returns: object
Get an evaluation: its inputs, build counts by status and its builds (filter by status).
status: all, failed (finished, not succeeded), succeeded or queued (not finished yet).
Inputs: eval_id (required), limit, status, instance. Returns: object
Get a job's build in the jobset's newest evaluation (any status) and its latest successful build.
Inputs: job (required), jobset (required), project (required), system, +1 more. Returns: object
Get a jobset's configuration, evaluation state and errors, plus its most recent evaluations.
Inputs: jobset (required), project (required), instance, recent_evals. Returns: object
Get one project's settings and the state of each of its jobsets (errors, last evaluation).
Inputs: project (required), instance. Returns: object
Get the build queue (highest priority first), its size by jobset, and the builds running right now.
Inputs: limit, instance. Returns: object
List a jobset's evaluations, newest first, one page at a time.
Inputs: jobset (required), project (required), page, instance. Returns: object
List the configured Hydra instances, the default one and whether each can log in for write tools.
Inputs: no named parameters. Returns: object
List the projects of a Hydra instance with their jobsets.
Inputs: instance. Returns: object
Restart an evaluation's failed or aborted builds, cancel its queued builds, or bump them to the front.
cancel is destructive: confirm with the user first.
Inputs: action (required), eval_id (required), instance. Returns: object
Create a jobset, or change the given fields of an existing one (others keep their values).
Give flake for a flake jobset, or nix_expression_input/path plus inputs for a legacy one.
Needs project ownership (or admin). New jobsets default to enabled, visible, no email, 300 s polling.
Inputs: jobset (required), project (required), flake, state, +11 more. Returns: object
Create a project, or change the given fields of an existing one (others keep their values).
Creating needs the create-projects role; editing needs project ownership.
Inputs: project (required), enabled, visible, homepage, +3 more. Returns: object
Re-queue a finished build (needs restart rights).
Inputs: build_id (required), instance. Returns: object
Search projects, jobsets, jobs and builds (by name, output or derivation path).
Inputs: query (required), instance. Returns: object
Ask Hydra to evaluate a jobset soon (needs restart rights on the project). force re-evaluates even if inputs are unchanged.
Inputs: jobset (required), project (required), force, instance. Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 18 tools
Most tools target a distinct resource and action (e.g., list_projects vs get_project, get_build vs get_build_log). There is minor overlap between manage_eval and the individual restart_build/cancel_build/bump_build tools, and between get_job and get_build, but descriptions clarify the boundaries.
The set predominantly follows a verb_noun convention (list_instances, get_project, trigger_evaluation, put_jobset). Exceptions like 'search' (verb only) and 'manage_eval' (vague verb) are minor deviations but still readable.
18 tools is slightly heavy but justified by the breadth of the Hydra CI domain: instances, projects, jobsets, evaluations, builds, queue, search, and mutation actions. Each tool covers a meaningful operation without obvious redundancy.
The surface covers read and write operations for projects, jobsets, evaluations, and builds, including queue and search. Minor gaps exist—no delete operations for projects or jobsets, and no direct way to cancel an entire evaluation—but core workflows are well supported.
Manage uivoid projects, tools, keys, hosted databases and teams from your agent.
Your agents' cloud for individuals and teams. Search, execute, packages, jobs, and credentials.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Discover Wiplash and manage owned agents with human OAuth.
